doesn't have to guess.

llvm-svn: 103194

locations in debug line info.

llvm-svn: 103189

at the token level. Consider the following horrible test case:

  a = 1
  .globl $a
  movl ($a), %eax
  movl $a, %eax
  movl $$a, %eax

llvm-svn: 103178

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.

llvm-svn: 103140

allow $ at the start of a symbol name.

llvm-svn: 103137

instructions to subtarget features and update tests to reflect.
PR5717.

llvm-svn: 103136

llvm-svn: 103133

llvm-svn: 103129

llvm-svn: 103122

llvm-svn: 103120

llvm-svn: 103114

llvm-svn: 103113

writing them.
 - <rdar://problem/7885351> integrated assembler broken for i386 objc code

llvm-svn: 103112

when possible.
 - <rdar://problem/7934873>

llvm-svn: 103092

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.

llvm-svn: 103038

"on the rare occasion the SPU BE produces illegal assembly - it tries to emit an add instruction of the form 'a reg, reg, imm'."

Patch by Kalle Raiskila!

llvm-svn: 103021

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...

llvm-svn: 103015

 - 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.

llvm-svn: 103012

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.

llvm-svn: 103007

llvm-svn: 103001

Do not ignore debug loc attached with llvm.dbg.declare while collecting debug info used by a module.

llvm-svn: 102995

on PPC for x!=0.  7624113.

llvm-svn: 102972

This fixes PR6941.

llvm-svn: 102970

when the type is floating-point.

llvm-svn: 102969

llvm-svn: 102964

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.

llvm-svn: 102958

mm to mm/m64 and the Move quadword from xmm2/mem64 to xmm1 had the incorrect
encodings.

llvm-svn: 102952

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.

llvm-svn: 102951

llvm-svn: 102948

Patch by Jakub Staszak!

llvm-svn: 102928

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.

llvm-svn: 102907

Remove the -enable-eh option which is only used by the JIT,
and replace it with -jit-enable-eh.

llvm-svn: 102865

other places, killing a valid transformation is not the right
answer.

llvm-svn: 102850

when needed. This fixes PR7001

llvm-svn: 102838

llvm-svn: 102836

llvm-svn: 102835

halting analysis, it is illegal to delete a call to a read-only function.
The correct solution is almost certainly to add a "must halt" attribute and
only allow deletions in its presence.

XFAIL the relevant testcase for now.

llvm-svn: 102831

if an indirect call site was removed and a direct one was added, not
just if an indirect call site was modified to be direct.

llvm-svn: 102830

llvm-svn: 102829

that can have a big effect :).  The first is to enable the
iterative SCC passmanager juice that kicks in when the
scc passmgr detects that a function pass has devirtualized
a call.  In this case, it will rerun all the passes it 
manages on the SCC, up to the iteration count limit (4). This
is useful because a function pass may devirualize a call, and
we want the inliner to inline it, or pruneeh to infer stuff
about it, etc.

The second patch is to add *all* call sites to the 
DevirtualizedCalls list the inliner uses.  This list is
about to get renamed, but the jist of this is that the 
inliner now reconsiders *all* inlined call sites as candidates
for further inlining.  The intuition is this that in cases 
like this:

f() { g(1); }     g(int x) { h(x); }

We analyze this bottom up, and may decide that it isn't 
profitable to inline H into G.  Next step, we decide that it is
profitable to inline G into F, and do so, which means that F 
now calls H.  Even though the call from G -> H may not have been
profitable to inline, the call from F -> H may be (in this case
because a constant allows folding etc).

In my spot checks, this doesn't have a big impact on code.  For
example, the LLC output for 252.eon grew from 0.02% (from
317252 to 317308) and 176.gcc actually shrunk by .3% (from 1525612
to 1520964 bytes).  252.eon never iterated in the SCC Passmgr,
176.gcc iterated at most 1 time.

llvm-svn: 102823