i64 and f64 types, but now it also handle Neon vector types, so the f64 result
of VMOVDRR may need to be converted to a Neon type. Radar 8084742.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105845 91177308-0d34-0410-b5e6-96231b3b80d8
This is a bit of a hack to make inline asm look more like call instructions.
It would be better to produce correct dead flags during isel.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105749 91177308-0d34-0410-b5e6-96231b3b80d8
the llvm tests :-(
It was failing with
-- Testing: 5324 tests, 8 threads --
Fatal Python error: PyEval_AcquireThread: NULL new thread state
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105610 91177308-0d34-0410-b5e6-96231b3b80d8
scrounging through SCEVUnknown contents and SCEVNAryExpr operands;
instead just do a simple deterministic comparison of the precomputed
hash data.
Also, since this is more precise, it eliminates the need for the slow
N^2 duplicate detection code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105540 91177308-0d34-0410-b5e6-96231b3b80d8
In file included from X86InstrInfo.cpp:16:
X86GenInstrInfo.inc:2789: error: integer constant is too large for 'long' type
X86GenInstrInfo.inc:2790: error: integer constant is too large for 'long' type
X86GenInstrInfo.inc:2792: error: integer constant is too large for 'long' type
X86GenInstrInfo.inc:2793: error: integer constant is too large for 'long' type
X86GenInstrInfo.inc:2808: error: integer constant is too large for 'long' type
X86GenInstrInfo.inc:2809: error: integer constant is too large for 'long' type
X86GenInstrInfo.inc:2816: error: integer constant is too large for 'long' type
X86GenInstrInfo.inc:2817: error: integer constant is too large for 'long' type
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105524 91177308-0d34-0410-b5e6-96231b3b80d8
there could be multiple subexpressions within a single expansion which
require insert point adjustment. This fixes PR7306.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105510 91177308-0d34-0410-b5e6-96231b3b80d8
replace an OpA with a widened OpB, it is possible to get new uses of OpA due to CSE
when recursively updating nodes. Since OpA has been processed, the new uses are
not examined again. The patch checks if this occurred and it it did, updates the
new uses of OpA to use OpB.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105453 91177308-0d34-0410-b5e6-96231b3b80d8
registers it defines then interfere with an existing preg live range.
For instance, if we had something like these machine instructions:
BB#0
... = imul ... EFLAGS<imp-def,dead>
test ..., EFLAGS<imp-def>
jcc BB#2 EFLAGS<imp-use>
BB#1
... ; fallthrough to BB#2
BB#2
... ; No code that defines EFLAGS
jcc ... EFLAGS<imp-use>
Machine sink will come along, see that imul implicitly defines EFLAGS, but
because it's "dead", it assumes that it can move imul into BB#2. But when it
does, imul's "dead" imp-def of EFLAGS is raised from the dead (a zombie) and
messes up the condition code for the jump (and pretty much anything else which
relies upon it being correct).
The solution is to know which pregs are live going into a basic block. However,
that information isn't calculated at this point. Nor does the LiveVariables pass
take into account non-allocatable physical registers. In lieu of this, we do a
*very* conservative pass through the basic block to determine if a preg is live
coming out of it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105387 91177308-0d34-0410-b5e6-96231b3b80d8
expansion is the same as that used by LegalizeDAG.
The resulting code sucks in terms of performance/codesize on x86-32 for a
64-bit operation; I haven't looked into whether different expansions might be
better in general.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105378 91177308-0d34-0410-b5e6-96231b3b80d8
iSel not properly lowring argument into a well formed DBG_VALUE in some cases is a separate issue and not related to the test in this testcase.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105295 91177308-0d34-0410-b5e6-96231b3b80d8
the newly created allocas may be used by inlined calls, so these
need to have their tail call flags cleared. Fixes PR7272.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105255 91177308-0d34-0410-b5e6-96231b3b80d8
that are too large. This causes the freebsd bootloader to be too
large apparently.
It's unclear if this should be an -Os or -Oz thing. Thoughts welcome.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105228 91177308-0d34-0410-b5e6-96231b3b80d8
optimization level.
This only really affects llc for now because both the llvm-gcc and clang front
ends override the default register allocator. I intend to remove that code later.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@104904 91177308-0d34-0410-b5e6-96231b3b80d8
The goal is to match following 3 lines. In otherwords, a temp. label between to DEBUG_VALUE comments.
;DEBUG_VALUE: bar:x <- undef ## 2010-01-18-Inlined-Debug.c:7
Ltmp1:
;DEBUG_VALUE: foo:__x <- undef ## 2010-01-18-Inlined-Debug.c:5
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@104872 91177308-0d34-0410-b5e6-96231b3b80d8
are st(0). These can be encoded using an opcode for storing in st(0) or using
an opcode for storing in st(i), where i can also be 0. To allow testing with
the darwin assembler and get a matching binary the opcode for storing in st(0)
is now used. To do this the same logical trick is use from the darwin assembler
in converting things like this:
fmul %st(0), %st
into this:
fmul %st(0)
by looking for the second operand being X86::ST0 for specific floating point
mnemonics then removing the second X86::ST0 operand. This also has the add
benefit to allow things like:
fmul %st(1), %st
that llvm-mc did not assemble.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@104634 91177308-0d34-0410-b5e6-96231b3b80d8
Mon Ping provided; unfortunately bugpoint failed to
reduce it, but I think it's important to have a test for
this in the suite. 8023512.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@104624 91177308-0d34-0410-b5e6-96231b3b80d8
Fix it by changing the T2I_rbin_s_is multiclass to handle the CPSR
output and 'S' suffix in the same way as T2I_bin_s_irs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@104531 91177308-0d34-0410-b5e6-96231b3b80d8
addw $0xFFFF, %ax
should match the same as
addw $-1, %ax
but we used to match it to the longer encoding.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@104453 91177308-0d34-0410-b5e6-96231b3b80d8
copying VFP subregs. This exposed a bunch of dead code in the *spill-q.ll
tests, so I tweaked those tests to keep that code from being optimized away.
Radar 7872877.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@104415 91177308-0d34-0410-b5e6-96231b3b80d8
so that it will continue to test what it was meant to test when I commit a
separate change for better support of BUILD_VECTOR and VECTOR_SHUFFLE for Neon.
Fix a DAG combiner crash exposed by this test change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@104380 91177308-0d34-0410-b5e6-96231b3b80d8
pass after isel instead of being interlaced with it, we can
trust that all the code for a function has been isel'd before
it is run.
The practical impact of this is that we can scan for machine
instr phis instead of doing a fuzzy match on the LLVM BB for
phi nodes. Doing the fuzzy match required knowing when isel
would produce an fp reg stack phi which was gross. It was
also wrong in cases where select got lowered to a branch
tree because cmovs aren't available (PR6828).
Just do the scan on machine phis which is simpler, faster
and more correct. This fixes PR6828.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@104333 91177308-0d34-0410-b5e6-96231b3b80d8
definitions of the virtual register.
This happens when spilling the registers produced by REG_SEQUENCE:
%reg1047:5<def>, %reg1047:6<def>, %reg1047:7<def> = VLD3d8 %reg1033, 0, pred:14, pred:%reg0
The rewriter would spill the register multiple times, dead store elimination
tried to keep up, but ended up cutting the branch it was sitting on.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@104321 91177308-0d34-0410-b5e6-96231b3b80d8
operand on the left, the interesting operand is on the right. This
fixes a bug where LSR was failing to recognize ICmpZero uses,
which led it to be unable to reverse the induction variable in the
attached testcase.
Delete test/CodeGen/X86/stack-color-with-reg-2.ll, because its test
is extremely fragile and hard to meaningfully update.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@104262 91177308-0d34-0410-b5e6-96231b3b80d8
the addressing modes don't make this trivially easy. This allows
it to avoid falling into the less precise heuristics in more
cases.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@104186 91177308-0d34-0410-b5e6-96231b3b80d8
lowering REG_SEQUENCE instructions.
Insert copies for REG_SEQUENCE sources not killed to avoid breaking later passes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@104146 91177308-0d34-0410-b5e6-96231b3b80d8
The trouble arises when the result of a vector cmp + sext is then and'ed with all ones. Instcombine will turn it into a vector cmp + zext, dag combiner will miss turning it into a vsetcc and hell breaks loose after that.
Teach dag combine to turn a vector cpm + zest into a vsetcc + and 1. This fixes rdar://7923010.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@104094 91177308-0d34-0410-b5e6-96231b3b80d8
correctly. The Lexer was incorrectly eating the newline casusing it to branch
to address 0. Updated the test case to use a "0:" label and a branch to "0b".
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@104038 91177308-0d34-0410-b5e6-96231b3b80d8
- This fixes a string table mismatch with 'as' when two new symbols are defined
in a single instruction.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103979 91177308-0d34-0410-b5e6-96231b3b80d8
- Don't clear weak reference flag, 'as' was only "trying" to do this, it wasn't
actually succeeding.
- Clear the "lazy bound" bit when we mark something external. This corresponds
roughly to the lazy clearing of the bit that 'as' implements in
symbol_table_lookup.
- The exact meaning of these flags appears pretty loose, since 'as' isn't very
consistent. For now we just try to match 'as', we will clean this up one day
hopefully.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103964 91177308-0d34-0410-b5e6-96231b3b80d8
variable has not yet been used in an expression. This allows us to support a few
cases that show up in real code (mostly because gcc generates it for Objective-C
on Darwin), without giving up a reasonable semantic model for assignment.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103950 91177308-0d34-0410-b5e6-96231b3b80d8
While that approach works wonders for register pressure, it tends to break
everything.
This should unbreak the arm-linux builder and fix a number of miscompilations.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103946 91177308-0d34-0410-b5e6-96231b3b80d8
<1xi64> -> i64 to work in MMX registers on hosts where -no-sse
is the default (not mine). The right thing is
to accept this and make i64->f64 conversions go through memory,
but I don't have time right now.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103914 91177308-0d34-0410-b5e6-96231b3b80d8
(This worked as of about 6 months ago and I didn't track down
exactly what broke it; I think this fix is appropriate.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103911 91177308-0d34-0410-b5e6-96231b3b80d8
allow target to override it in order to map register classes to illegal
but synthesizable types. e.g. v4i64, v8i64 for ARM / NEON.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103854 91177308-0d34-0410-b5e6-96231b3b80d8
replace the check with the appropriate predicate. Modify the testcase to reflect
the correct code. (It should be saving callee-saved registers on the stack
allocated by the calling fuction.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103829 91177308-0d34-0410-b5e6-96231b3b80d8
-filetype=obj test, and -filetype=obj leaks a few objects. Added a FIXME, we
need to sort out the ownership model for the various MC objects.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103769 91177308-0d34-0410-b5e6-96231b3b80d8
ParseDirectiveDarwinZerofill instead of hard coding the
check for identifier. This allows quoted symbol names to
be used.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103682 91177308-0d34-0410-b5e6-96231b3b80d8
lower them to the correct x86-64 instructions since we
don't have a clean way to handle this in td files yet.
rdar://7947184
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103668 91177308-0d34-0410-b5e6-96231b3b80d8
be diced into atoms, and adjust getAtom() to take this into account.
- This fixes relocations to symbols in fixed size literal sections, for
example.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103532 91177308-0d34-0410-b5e6-96231b3b80d8
This allows us to add accurate kill markers, something the scavenger likes.
Add some more tests from ARM that needed this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103521 91177308-0d34-0410-b5e6-96231b3b80d8
Sorry for the big change. The path leading up to this patch had some TableGen
changes that I didn't want to commit before I knew they were useful. They
weren't, and this version does not need them.
The fast register allocator now does no liveness calculations. Instead it relies
on kill flags provided by isel. (Currently those kill flags are also ignored due
to isel bugs). The allocation algorithm is supposed to work with any subset of
valid kill flags. More kill flags simply means fewer spills inserted.
Registers are allocated from a working set that contains no aliases. That means
most allocations can be done directly without expensive alias checks. When the
working set runs out of registers we do the full alias check to find new free
registers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103488 91177308-0d34-0410-b5e6-96231b3b80d8
- This eliminates getAtomForAddress() (which was a linear search) and
simplifies getAtom().
- This also fixes some correctness problems where local labels at the same
address as non-local labels could be assigned to the wrong atom.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103480 91177308-0d34-0410-b5e6-96231b3b80d8
This includes a patch by Roman Divacky to fix the initial crash.
Move the actual addition of passes from *PassManager::add to
*PassManager::addImpl. That way, when adding printer passes we won't
recurse infinitely.
Finally, check to make sure that we are actually adding a FunctionPass
to a FunctionPassManager before doing a print before or after it.
Immutable passes are strange in this way because they aren't
FunctionPasses yet they can be and are added to the FunctionPassManager.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103425 91177308-0d34-0410-b5e6-96231b3b80d8
when it detects undefined behavior. llvm.trap generally codegens into some
thing really small (e.g. a 2 byte ud2 instruction on x86) and debugging this
sort of thing is "nontrivial". For example, we now compile:
void foo() { *(int*)0 = 42; }
into:
_foo:
pushl %ebp
movl %esp, %ebp
ud2
Some may even claim that this is a security hole, though that seems dubious
to me. This addresses rdar://7958343 - Optimizing away null dereference
potentially allows arbitrary code execution
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103356 91177308-0d34-0410-b5e6-96231b3b80d8
with a vector input and output into a shuffle vector. This sort of
sequence happens when the input code stores with one type and reloads
with another type and then SROA promotes to i96 integers, which make
everyone sad.
This fixes rdar://7896024
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103354 91177308-0d34-0410-b5e6-96231b3b80d8
LSRUse's Regs set after all pruning is done, rather than trying
to do it on the fly, which can produce an incomplete result.
This fixes a case where heuristic pruning was stripping all
formulae from a use, which led the solver to enter an infinite
loop.
Also, add a few asserts to diagnose this kind of situation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103328 91177308-0d34-0410-b5e6-96231b3b80d8
getConstantFP to accept the two supported long double
target types. This was not the original intent, but
there are other places that assume this works and it's
easy enough to do.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103299 91177308-0d34-0410-b5e6-96231b3b80d8
and %rcr_, leaving just %cr_ which is what people expect.
Updated the disassembler to support this unified register set.
Added a testcase to verify that the registers continue to be
decoded correctly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103196 91177308-0d34-0410-b5e6-96231b3b80d8
at the token level. Consider the following horrible test case:
a = 1
.globl $a
movl ($a), %eax
movl $a, %eax
movl $$a, %eax
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103178 91177308-0d34-0410-b5e6-96231b3b80d8
Users can write broken code that emits the same label twice with asm renaming,
detect this and emit a fatal backend error instead of aborting.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103140 91177308-0d34-0410-b5e6-96231b3b80d8
values passed to llvm.dbg.value were not valid for the intrinsic, it
might have caused trouble one day if the verifier ever started checking
for valid debug info.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103038 91177308-0d34-0410-b5e6-96231b3b80d8
instructions which have no direct register usage.
Darwin 'as' accepts:
add $0, (%rax)
but rejects
mov $0, (%rax)
for example.
Given that, only accept suffix matches which match exactly one form. We still
need to emit nice diagnostics for failures...
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103015 91177308-0d34-0410-b5e6-96231b3b80d8
- The idea is that when a match fails, we just try to match each of +'b', +'w',
+'l'. If exactly one matches, we assume this is a mnemonic prefix and accept
it. If all match, we assume it is width generic, and take the 'l' form.
- This would be a horrible hack, if it weren't so simple. Therefore it is an
elegant solution! Chris gets the credit for this particular elegant
solution. :)
- Next step to making this more robust is to have the X86 matcher generate the
mnemonic prefix information. Ideally we would also compute up-front exactly
which mnemonic to attempt to match, but this may require more custom code in
the matcher than is really worth it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103012 91177308-0d34-0410-b5e6-96231b3b80d8
RAUW of a global variable with a local variable in function F,
if function local metadata M in function G was using the global
then M would become function-local to both F and G, which is not
allowed. See the testcase for an example. Fixed by detecting
this situation and zapping the metadata operand when it occurs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103007 91177308-0d34-0410-b5e6-96231b3b80d8