If vector types have legal register classes, then LLVM bypasses LegalizeTypes
on them, which causes faults currently since the code to handle them isn't in
place.
This fixes test failures when AArch64 is the default target.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@175172 91177308-0d34-0410-b5e6-96231b3b80d8
The parser will now accept instructions with alignment specifiers written like
vld1.8 {d16}, [r0:64]
, while also still accepting the incorrect syntax
vld1.8 {d16}, [r0, :64]
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@175164 91177308-0d34-0410-b5e6-96231b3b80d8
up so that we can apply the direct object emitter patch. This patch
should be a nop right now and it's test is to not break what is already
there.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@175126 91177308-0d34-0410-b5e6-96231b3b80d8
Since functions with internal linkage don't have language linkage, it is valid
to overload them:
extern "C" {
static int foo();
static int foo(int);
}
So we mangle them.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@175120 91177308-0d34-0410-b5e6-96231b3b80d8
if the offset fits in 11 bits. This makes use of the fact that the abi
requires sp to be 8 byte aligned so the actual offset can fit in 8
bits. It will be shifted left and sign extended before being actually used.
The assembler or direct object emitter will shift right the 11 bit
signed field by 3 bits. We don't need to deal with that here.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@175073 91177308-0d34-0410-b5e6-96231b3b80d8
This happens when there is both stack realignment and a dynamic alloca in the
function. If we overwrite %esi (rep;movsl uses fixed registers) we'll lose the
base pointer and the next register spill will write into oblivion.
Fixes PR15249 and unbreaks firefox on i386/freebsd. Mozilla uses dynamic allocas
and freebsd a 4 byte stack alignment.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@175057 91177308-0d34-0410-b5e6-96231b3b80d8
Vectors were being manually scalarized by the backend. Instead,
let the target-independent code do all of the work. The manual
scalarization was from a time before good target-independent support
for scalarization in LLVM. However, this forces us to specially-handle
vector loads and stores, which we can turn into PTX instructions that
produce/consume multiple operands.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174968 91177308-0d34-0410-b5e6-96231b3b80d8
'R600/SI: Use proper instructions for array/shadow samplers.' removed two
cases from TEX_SHADOW. Vincent Lejeune reported on IRC that this broke some
shadow array piglit tests with the r600g driver. Reinstating the removed
cases should fix this, and still works with radeonsi as well.
I will follow up with some lit tests which would have caught the regression.
NOTE: This is a candidate for the Mesa stable branch.
Tested-by: Vincent Lejeune <vljn@ovi.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174963 91177308-0d34-0410-b5e6-96231b3b80d8
Lower reverse shuffles to a vrev64 and a vext instruction instead of the default
legalization of storing and loading to the stack. This is important because we
generate reverse shuffles in the loop vectorizer when we reverse store to an
array.
uint8_t Arr[N];
for (i = 0; i < N; ++i)
Arr[N - i - 1] = ...
radar://13171760
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174929 91177308-0d34-0410-b5e6-96231b3b80d8
Fixed decode of existing 3dNow prefetchw instruction
Intel is scheduled to add a compatible prefetchw (same encoding) to future CPUs
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174920 91177308-0d34-0410-b5e6-96231b3b80d8
MipsCodeEmitter.cpp.
JALR and NOP are expanded by function emitPseudoExpansionLowering, which is not
called when the old JIT is used.
This fixes the following tests which have been failing on
llvm-mips-linux builder:
LLVM :: ExecutionEngine__2003-01-04-LoopTest.ll
LLVM :: ExecutionEngine__2003-05-06-LivenessClobber.ll
LLVM :: ExecutionEngine__2003-06-04-bzip2-bug.ll
LLVM :: ExecutionEngine__2005-12-02-TailCallBug.ll
LLVM :: ExecutionEngine__2003-10-18-PHINode-ConstantExpr-CondCode-Failure.ll
LLVM :: ExecutionEngine__hello2.ll
LLVM :: ExecutionEngine__stubs.ll
LLVM :: ExecutionEngine__test-branch.ll
LLVM :: ExecutionEngine__test-call.ll
LLVM :: ExecutionEngine__test-common-symbols.ll
LLVM :: ExecutionEngine__test-loadstore.ll
LLVM :: ExecutionEngine__test-loop.ll
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174912 91177308-0d34-0410-b5e6-96231b3b80d8
The modifiers don't seem to have any effect with V_MOV_B32, supposedly it's
meant to just move bits untouched.
Fixes 46 piglit tests with radeonsi, though unfortunately 11 of those had
just regressed because they started using the clamp modifier.
NOTE: This is a candidate for the Mesa stable branch.
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174890 91177308-0d34-0410-b5e6-96231b3b80d8
This does two things:
It removes a call to abs() which may have "long long" parameter on Windows,
which is not necessarily available in C++03.
It also corrects the signedness of Amount, which was relying on
implementation-defined conversions previously.
Code was already tested (albeit in an implemnetation defined way) so no extra
tests.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174885 91177308-0d34-0410-b5e6-96231b3b80d8
Previous code had a confusing comment which was mostly an implementation
detail. This condition corresponds to "lsb up to register width" and "width not
ridiculous".
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174877 91177308-0d34-0410-b5e6-96231b3b80d8
This gives a DiagnosticType to all AsmOperands in sight. This replaces all
"invalid operand" diagnostics with something more specific. The messages given
should still be sufficiently vague that they're not usually actively misleading
when LLVM guesses your instruction incorrectly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174871 91177308-0d34-0410-b5e6-96231b3b80d8
function is successfully handled by fast-isel. That's because function
arguments are *always* handled by SDISel. Introduce FastLowerArguments to
allow each target to provide hook to handle formal argument lowering.
As a proof-of-concept, add ARMFastIsel::FastLowerArguments to handle
functions with 4 or fewer scalar integer (i8, i16, or i32) arguments. It
completely eliminates the need for SDISel for trivial functions.
rdar://13163905
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174855 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes a couple of bugs and incorrect assumptions,
in total four more piglit tests now pass.
v2: fix small bug in the dominator updating
Patch by: Christian König
Signed-off-by: Christian König <christian.koenig@amd.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174762 91177308-0d34-0410-b5e6-96231b3b80d8
Patch by: Christian König
Intersecting loop handling was wrong.
Signed-off-by: Christian König <christian.koenig@amd.com>
Tested-by: Michel Dänzer <michel.daenzer@amd.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174761 91177308-0d34-0410-b5e6-96231b3b80d8
Otherwise we sometimes produce invalid code.
Patch by: Christian König
Signed-off-by: Christian König <christian.koenig@amd.com>
Tested-by: Michel Dänzer <michel.daenzer@amd.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174760 91177308-0d34-0410-b5e6-96231b3b80d8
same so we put in the comment field an indicator when we think we are
emitting the 16 bit version. For the direct object emitter, the difference is
important as well as for other passes which need an accurate count of
program size. There will be other similar putbacks to this for various
instructions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174747 91177308-0d34-0410-b5e6-96231b3b80d8
Thanks to help from Nadav and Hal, I have a more reasonable (and even
correct!) approach. This specifically penalizes the insertelement
and extractelement operations for the performance hit that will occur
on PowerPC processors.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174725 91177308-0d34-0410-b5e6-96231b3b80d8
Adds a function to target transform info to query for the cost of address
computation. The cost model analysis pass now also queries this interface.
The code in LoopVectorize adds the cost of address computation as part of the
memory instruction cost calculation. Only there, we know whether the instruction
will be scalarized or not.
Increase the penality for inserting in to D registers on swift. This becomes
necessary because we now always assume that address computation has a cost and
three is a closer value to the architecture.
radar://13097204
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174713 91177308-0d34-0410-b5e6-96231b3b80d8
