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

This fixes PR6941.

llvm-svn: 102970

when the type is floating-point.

llvm-svn: 102969

llvm-svn: 102966

same, now that getConstant has overloads consistent with ConstantInt::get.

llvm-svn: 102965

llvm-svn: 102964

since llvmCore is built as part of llvmgcc42 now.

llvm-svn: 102962

variable.  Surprisingly, this does seem to be the right way to solve this.

llvm-svn: 102961

debug output is showing machine instructions, the IR-level basic block names
aren't very meaningful, and because multiple machine basic blocks may be
derived from one IR-level BB, they're also not unique.

llvm-svn: 102960

llvm-svn: 102959

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