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

indirect branches in all the predecessors.  This avoids unnecessarily
splitting edges in cases where load PRE is not possible anyway.
Thanks to Jakub Staszak for pointing this out.

llvm-svn: 103034

llvm-svn: 103028

    typedef int functype(int, int);
    functype func;

also instantiate the synthesized function parameters for the resulting
function declaration. 

With this change, Boost.Wave builds and passes all of its regression
tests.

llvm-svn: 103025

llvm-svn: 103024

llvm-svn: 103023

(radar 7495203).

llvm-svn: 103022

"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

printed in a diagnostic, similar to the limit we already have on the
depth of the template instantiation backtrace. The macro instantiation
backtrace is limited to 10 "instantiated from:" diagnostics; when it's
longer than that, we'll show the first half, then say how many were
suppressed, then show the second half. The limit can be changed with
-fmacro-instantiation-limit=N, and turned off with N=0.

This eliminates a lot of note spew with libraries making use of the
Boost.Preprocess library.

llvm-svn: 103014

llvm-svn: 103013

 - 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

implicitly-defined copy assignment operator, suppress the protected
access check. This eliminates the remaining failure in the
Boost.SmartPtr library (that was a product of the copy-assignment
generation rewrite) and, presumably, the Boost.TR1 library as well.

llvm-svn: 103010

buildbot: the debugging and non-debugging versions of getFunction were not
functionally equivalent: the non-debugging version wrongly assumed that if a
metadata operand was not metadata, then it had a non-null containing function.
This is not true, since the operand might be a global value, constant etc.

llvm-svn: 103008

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: 103006

llvm-svn: 103003

llvm-svn: 103001

llvm-svn: 103000

class.  Add some conservative support for the idea.  Fixes PR 7024.

llvm-svn: 102999

not just the inner expression.  This is important if the expression has any
temporaries.  Fixes PR 7028.

Basically a symptom of really tragic method names.

llvm-svn: 102998

of doing the same thing manually.

llvm-svn: 102997

llvm-svn: 102996

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

llvm-svn: 102995

Instruction selection optimizations may have moved the def of a function argument out of the entry block. rdar://7937489

llvm-svn: 102993

changed to 0x7E from 0x6E as well as the previous change of RPDI to S3SI.

llvm-svn: 102991

name (for example, to allow targets to interpose the actual MatchInstruction
function).

llvm-svn: 102987

match failure.

Also, fixes a few memory leak FIXMEs.

llvm-svn: 102986

variabe. Blocks and their construction/destruction is
wip though. 

llvm-svn: 102985

llvm-svn: 102984

used together in either order.

llvm-svn: 102983

llvm-svn: 102981

eliminateFrameIndex(), leading to llvm_unreachable() assertion failure.

llvm-svn: 102980

llvm-svn: 102978

update the big red warning at the top. Most of the old content remains
and awaits revision.

Clear out the API changes section, and start it up again with a
mention of the add->fadd transition.

llvm-svn: 102977

This should make it possible to start producing kill flags in isel without
breaking stuff.

llvm-svn: 102976

in registers into a separate function to de-couple it from the
top-down-specific logic in getRegForValue.

llvm-svn: 102975

friend function template, be sure to adjust the computed template
argument lists based on the location of the definition of the function
template: it's possible that the definition we're instantiating with
and the template declaration that we found when creating the
specialization are in different contexts, which meant that we would
end up using the wrong template arguments for instantiation.

Fixes PR7013; all Boost.DynamicBitset tests now pass.

llvm-svn: 102974

on PPC for x!=0.  7624113.

llvm-svn: 102972

to fadd, fsub, and fmul, when used with a floating-point type. LLVM
has supported the new instructions since 2.6, so it's time to get
on board.

llvm-svn: 102971