If this code triggers, any immediate has already been validated so it can't
possibly trigger a diagnostic.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208564 91177308-0d34-0410-b5e6-96231b3b80d8
In terms of assembly, these have too much overlap to be neatly modelled as
disjoint classes: in many cases "lsl" is an acceptable alternative to either
"uxtw" or "uxtx".
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208563 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This required a new instruction group representing the 32-bit subset of
MIPS-V that was available in MIPS32R2
Most of these instructions are correctly rejected but with the wrong error
message. These have been placed in a separate test for now. It happens
because many of the MIPS V instructions have not been implemented.
Depends on D3694
Reviewers: vmedic
Reviewed By: vmedic
Differential Revision: http://reviews.llvm.org/D3695
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208546 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
DCL[ZO] are now correctly marked as being MIPS64 instructions. This has no
effect on the CodeGen tests since expansion of i64 prevented their use
anyway.
The check for MIPS16 to prevent the use of CLZ no longer prevents DCLZ as
well. This is not a functional change since DCLZ is still prohibited by
being a MIPS64 instruction (MIPS16 is only compatible with MIPS32).
No functional change
Reviewers: vmedic
Reviewed By: vmedic
Differential Revision: http://reviews.llvm.org/D3694
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208544 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
dsbh and dshd are not available on Mips32r2. No codegen test changes
required since expansion of i64 prevented the use of these instructions
anyway.
Depends on D3690
Reviewers: vmedic
Reviewed By: vmedic
Differential Revision: http://reviews.llvm.org/D3692
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208542 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
No functional change.
The minor change to the MIPS16 code is in preparation for a patch that will handle 32-bit FPIdx instructions separately to 64-bit (because they were added in different revisions)
Depends on D3677
Reviewers: rkotler, vmedic
Reviewed By: vmedic
Differential Revision: http://reviews.llvm.org/D3690
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208541 91177308-0d34-0410-b5e6-96231b3b80d8
In transformation:
BinOp(shuffle(v1,undef), shuffle(v2,undef)) -> shuffle(BinOp(v1, v2),undef)
type of the undef argument must be same as type of BinOp.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208531 91177308-0d34-0410-b5e6-96231b3b80d8
Unfortunately, since ARM64 models all these instructions as aliases,
the checks need to be done at the time the alias is seen rather than
during instruction validation as AArch64 does it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208529 91177308-0d34-0410-b5e6-96231b3b80d8
1) Changed gather and scatter intrinsics. Now they are aligned with GCC built-ins. There is no more non-masked form. Masked intrinsic receives -1 if all lanes are executed.
2) I changed the function that works with intrinsics inside X86ISelLowering.cpp. I put all intrinsics in one table. I did it for INTRINSICS_W_CHAIN and plan to put all intrinsics from WO_CHAIN set to the same table in order to avoid the long-long "switch". (I wanted to use static map initialization that allowed by C++11 but I wasn't able to compile it on VS2012).
3) I added gather/scatter prefetch intrinsics.
4) I fixed MRMm encoding for masked instructions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208522 91177308-0d34-0410-b5e6-96231b3b80d8
Do not apply transformation:
BinOp(shuffle(v1), shuffle(v2)) -> shuffle(BinOp(v1, v2))
if operands v1 and v2 are of different size.
This change fixes PR19717, which was caused by r208488.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208518 91177308-0d34-0410-b5e6-96231b3b80d8
Support for the intrinsics that read from and write to global named registers
is added for r1, r2 and r13 (depending on the subtarget).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208509 91177308-0d34-0410-b5e6-96231b3b80d8
We must validate the value type in TLI::getRegisterByName, because if we
don't and the wrong type was used with the IR intrinsic, then we'll assert
(because we won't be able to find a valid register class with which to
construct the requested copy operation). For PPC64, additionally, the type
information is necessary to decide between the 64-bit register and the 32-bit
subregister.
No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208508 91177308-0d34-0410-b5e6-96231b3b80d8
This test was using the inliner and other optimizations to test a case
that's actually a bug anyway. Bug and possible fix/discussion described
here ( http://reviews.llvm.org/D3714 ).
But the functionality that was implemented along with this test is still
desired, so simplify the test to verify a more obvious/less wrong case
that the functionality addressed: looking through const sugar to the
underlying type when emitting a constant (so the constant is emitted as
signed/unsigned as appropriate depending on the signedness of the
underlying type).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208504 91177308-0d34-0410-b5e6-96231b3b80d8
Filed as PR19712, LLVM fails to detect the right type of an enum
constant when a frontend does not provide an underlying type for the
enumeration type.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208502 91177308-0d34-0410-b5e6-96231b3b80d8
The counter-loops formation pass needs to know what operations might be
function calls (because they can't appear in counter-based loops). On PPC32,
128-bit shifts might be runtime calls (even though you can't use __int128 on
PPC32, it seems that SROA might form them).
Fixes PR19709.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208501 91177308-0d34-0410-b5e6-96231b3b80d8
And the winner by a nose is isUnsignedDIType, for no particular reason.
These two functions were just complements of each other and used in very
related code, so refactor callers to just use one of them.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208500 91177308-0d34-0410-b5e6-96231b3b80d8
Doesn't seem a good reason to duplicate this code (it was more literally
duplicated prior to r208494, and while the dataN code /does/ actually
fire in this case, it doesn't seem necessary (and the DWARF standard
recommends using udata/sdata pervasively instead of dataN, so as to
indicate signedness of the values))
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208495 91177308-0d34-0410-b5e6-96231b3b80d8
This code looks to have become dead at some time in the past. I tried to
reproduce cases where LLVM would emit constants with dataN, but could
not. Upon inspection it seems the code doesn't do that anymore - the
only time a size is provided by isTypeSigned is when the type is signed,
and in those cases we use sdata. dataN is only used for unsigned types
and isTypeSigned doesn't provide a value for sizeInBits in that case.
Remove the dead cases/size plumbing.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208494 91177308-0d34-0410-b5e6-96231b3b80d8
Turns out that there is a very cheap way of testing whether a block is dead,
just look it up in the DomTree. We have to do this anyways so just ignore
unreachable blocks before sorting by domination. This restores a proper
ordering for std::stable_sort when dead code is present.
Covered by existing tests & buildbots running in STL debug mode (MSVC).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208492 91177308-0d34-0410-b5e6-96231b3b80d8
This patch enables transformations:
BinOp(shuffle(v1), shuffle(v2)) -> shuffle(BinOp(v1, v2))
BinOp(shuffle(v1), const1) -> shuffle(BinOp, const2)
They allow to eliminate extra shuffles in some cases.
Differential Revision: http://reviews.llvm.org/D3525
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208488 91177308-0d34-0410-b5e6-96231b3b80d8
When lowering build_vector to an insertps, we would still lower it, even
if the source vectors weren't v4x32. This would break on avx if the source
was a v8x32. We now check the type of the source vectors.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208487 91177308-0d34-0410-b5e6-96231b3b80d8
