occasions, caused code to be generated in a different order.
All cases I've seen involved float softening in the type
legalizer, and this could be perhaps be fixed there, but
it's better not to generate things differently in the first
place.  7797940 (6/29/2010..7/15/2010).

llvm-svn: 108484

llvm-svn: 108483

 - This issue here is that /usr/include/Blocks.h wants to define some of the
   block runtime globals as weak, depending on the target. This doesn't work in
   Clang because we aren't using the AST decl for these globals.

 - The fix is a pretty gross hack which just watches all the decls for the
   specific blocks globals we need to know about; if we see one we use it,
   otherwise we use the hand coded type.

   In time, I would like to clean this up by changing IRgen to ask Sema/AST for
   the decl, which would then be lazily loaded from the builtin table if
   necessary. This could be used in a whole host of places in IRgen and would
   get rid of a lot of grotty hand coding of LLVM IR; however, we need some
   extra Sema support for this as well as support for builtin global variables.

llvm-svn: 108482

llvm-svn: 108481

llvm-svn: 108480

llvm-svn: 108478

the order they appeared in the translation unit.  If they get emitted, put them
in their proper order.  Fixes rdar://problem/7458115

llvm-svn: 108477

it doesn't miss an opportunity to form a GEP, regardless of the
relative loop depths of the operands. This fixes rdar://8197217.

llvm-svn: 108475

the function. We'll just turn it into a "trap" instruction instead.

The problem with not handling this is that it might generate a prologue without
the equivalent epilogue to go with it:

$ cat t.ll
define void @foo() {
entry:
  unreachable
}
$ llc -o - t.ll -relocation-model=pic -disable-fp-elim -unwind-tables
        .section        __TEXT,__text,regular,pure_instructions
        .globl  _foo
        .align  4, 0x90
_foo:                                   ## @foo
Leh_func_begin0:
## BB#0:                                ## %entry
        pushq   %rbp
Ltmp0:
        movq    %rsp, %rbp
Ltmp1:
Leh_func_end0:
...

The unwind tables then have bad data in them causing all sorts of problems.

Fixes <rdar://problem/8096481>.

llvm-svn: 108473

Set "optimization is ON" and supply other optional parameters. This helps codegenerator preserve info in case the symbol is deleted.

llvm-svn: 108471

llvm-svn: 108470

with always_inline attribute. Thanks to Howard for the tip.

llvm-svn: 108469

Tested by namespace.exp and virtfunc.exp from gdb testsuite.

llvm-svn: 108468

the same.

llvm-svn: 108467

-enable-no-nans-fp-math and -enable-no-infs-fp-math. All of the current codegen fp math optimizations only care whether the fp arithmetics arguments and results can never be NaN.

llvm-svn: 108465

for string literals.

llvm-svn: 108464

llvm-svn: 108463

ambiguity problems on some systems.

llvm-svn: 108462

to keep "Text" in sync with the "pure instructions" section attribute.
Lack of this attribute was preventing the assembler from emitting
multibyte noops instructions for templates (and inlines, and other
coalesced stuff) and was causing the assembler to mismatch .o files.

This fixes rdar://8018335

llvm-svn: 108461

llvm-svn: 108460

parser is looking at a declaration or an expression, use a '=' to
conclude that we are parsing a declaration.

This is wrong. However, our previous approach of finding a comma after
the '=' is also wrong, because the ',' could be part of a
template-argument-list. So, for now we're going to use the same wrong
heuristic as GCC and Visual C++, because less real-world code is
likely to be broken this way. I've opened PR7655 to keep track of our
wrongness; note also the XFAIL'd test.

Fixes <rdar://problem/8193163>.

llvm-svn: 108459

llvm-svn: 108458

llvm-svn: 108457

llvm-svn: 108456

different widths. In a use with a narrower fixup, formulae
may be wider than the fixup, in which case the high bits
aren't necessarily meaningful, so it isn't safe to reuse
them for uses with wider fixups.

This fixes PR7618, though the testcase is too large for a
reasonable regression test, since it heavily dependes on
hitting LSR's heuristics in a certain way.

llvm-svn: 108455

this fixes rdar://8192860.  Unfortunately it can only be triggered
with llc because llvm-mc matches another (correctly encoded) version
of this, so no testcase.

llvm-svn: 108454

llvm-svn: 108453

llvm-svn: 108452

This helps LSR behave more consistently on bugpoint-reduced testcases.

llvm-svn: 108451

llvm-svn: 108450

make sure to allocate enough space in the std::vector.

llvm-svn: 108449

llvm-svn: 108448

llvm-svn: 108445

llvm-svn: 108444

with the proper spelling of "non-class prvalue". Silly me, I think
class rvalues were xvalues rather than prvalues!

Hah hah hah.

llvm-svn: 108443

that we don't warn when there isn't going to be any computation anyway.

llvm-svn: 108442

llvm-svn: 108441

llvm-svn: 108440

broke nightlytest.

llvm-svn: 108439

llvm-svn: 108438