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
instructions as the Mac OS X darwin assembler. Some of which like 'fcoml'
assembled to different opcodes. While some of the suffixes were just different.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102958 91177308-0d34-0410-b5e6-96231b3b80d8
caused the a pushl instruction to be incorrectly encoding using only two bytes
of immediate, causing the following 2 instruction bytes to be part of the 32-bit
immediate value. Also fixed the one byte form of push to be used when the
immediate would fit in a signed extended byte. Lastly changed the names to not
include the 32 of PUSH32 since they actually push the size of the stack pointer.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102951 91177308-0d34-0410-b5e6-96231b3b80d8
beneficial cases. See the changes in test/CodeGen/X86/tail-opts.ll and
test/CodeGen/ARM/ifcvt2.ll for details.
The fix is to change HashEndOfMBB to hash at most one instruction,
instead of trying to apply heuristics about when it will be profitable to
consider more than one instruction. The regular tail-merging heuristics
are already prepared to handle the same cases, and they're more precise.
Also, make test/CodeGen/ARM/ifcvt5.ll and
test/CodeGen/Thumb2/thumb2-branch.ll slightly more complex so that they
continue to test what they're intended to test.
And, this eliminates the problem in
test/CodeGen/Thumb2/2009-10-15-ITBlockBranch.ll, the testcase from
PR5204. Update it accordingly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102907 91177308-0d34-0410-b5e6-96231b3b80d8
