llvm-svn: 76198

revert one of the loops to use indicies over iterators because there are vector insertions inside the loop

llvm-svn: 76195

llvm-svn: 76153

llvm-svn: 76131

llvm-svn: 76123

stack alignment right when it is.  This is not
ideal but conservatively correct.  Adjust a test
to compensate for changed stack offset value.
gcc.apple/asm-block-57.c

llvm-svn: 76120

Emit line numbers in asm comments when available.

llvm-svn: 76117

llvm-svn: 76111

call to the MachineCodeEmitter interface and made copying the start
line of a function not conditional on whether we're emitting Dwarf
debug information. I'll propagate the processDebugLoc() calls to the
non-X86 targets in a followup patch.

In the long run, it'll probably be better to gather this information
through the DwarfWriter, but the DwarfWriter currently depends on the
AsmPrinter and TargetAsmInfo, and fixing that would be out of the way
for this patch.

There's a bug in OProfile 0.9.4 that makes it ignore line numbers for
addresses above 4G, and a patch fixing it at
http://thread.gmane.org/gmane.linux.oprofile/7634

Sample output:

$ sudo opcontrol --reset; sudo opcontrol --start-daemon; sudo opcontrol --start; `pwd`/Debug/bin/lli fib.bc; sudo opcontrol --stop
Signalling daemon... done
Profiler running.
fib(40) == 165580141
Stopping profiling.

$ opreport -g -d -l `pwd`/Debug/bin/lli|head -60
Overflow stats not available
CPU: Core 2, speed 1998 MHz (estimated)
Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask of 0x00 (Unhalted core cycles) count 100000
vma      samples  %        linenr info                 image name               symbol name
00007f67a30370b0 25489    61.2554  fib.c:24                    10946.jo                 fib_left
  00007f67a30370b0 1634      6.4106  fib.c:24
  00007f67a30370b1 83        0.3256  fib.c:24
  00007f67a30370b9 1997      7.8348  fib.c:24
  00007f67a30370c6 2080      8.1604  fib.c:27
  00007f67a30370c8 988       3.8762  fib.c:27
  00007f67a30370cd 1315      5.1591  fib.c:27
  00007f67a30370cf 251       0.9847  fib.c:27
  00007f67a30370d3 1191      4.6726  fib.c:27
  00007f67a30370d6 975       3.8252  fib.c:27
  00007f67a30370db 1010      3.9625  fib.c:27
  00007f67a30370dd 242       0.9494  fib.c:27
  00007f67a30370e1 2782     10.9145  fib.c:28
  00007f67a30370e5 3768     14.7828  fib.c:28
  00007f67a30370eb 615       2.4128  (no location information)
  00007f67a30370f3 6558     25.7287  (no location information)
00007f67a3037100 15603    37.4973  fib.c:29                    10946.jo                 fib_right
  00007f67a3037100 1646     10.5493  fib.c:29
  00007f67a3037101 45        0.2884  fib.c:29
  00007f67a3037109 2372     15.2022  fib.c:29
  00007f67a3037116 2234     14.3178  fib.c:32
  00007f67a3037118 612       3.9223  fib.c:32
  00007f67a303711d 622       3.9864  fib.c:32
  00007f67a303711f 385       2.4675  fib.c:32
  00007f67a3037123 404       2.5892  fib.c:32
  00007f67a3037126 634       4.0633  fib.c:32
  00007f67a303712b 870       5.5759  fib.c:32
  00007f67a303712d 62        0.3974  fib.c:32
  00007f67a3037131 1848     11.8439  fib.c:33
  00007f67a3037135 2840     18.2016  fib.c:33
  00007f67a303713a 1         0.0064  fib.c:33
  00007f67a303713b 1023      6.5564  (no location information)
  00007f67a3037143 5         0.0320  (no location information)
000000000080c1e4 15        0.0360  MachineOperand.h:150        lli                      llvm::MachineOperand::isReg() const
  000000000080c1e4 6        40.0000  MachineOperand.h:150
  000000000080c1ec 2        13.3333  MachineOperand.h:150
...

llvm-svn: 76102

The inline asm operands must be parsed from the first flag, you cannot assume
that an immediate operand preceeding a register use operand is the flag.
PowerPC "m" operands are represented as (flag, imm, reg) triples.
isRegTiedToDefOperand() would incorrectly interpret the imm as the flag.

llvm-svn: 76101

llvm-svn: 76100

llvm-svn: 76097

our current context-passing stuff, which is also fixed here

llvm-svn: 76089

llvm-svn: 75955

Scan for presence of calls and determine max callframe size early. To allow ProcessFunctionBeforeCalleeSaveScan() use this information

llvm-svn: 75942

llvm-svn: 75925

Avoid remat'ing instructions whose def have sub-register indices for now. It's just really really hard to get all the cases right.

llvm-svn: 75900

llvm-svn: 75898

This prefix is used by LLVM to inform the asm printer to not emit usual global symbol prefix before the symbol name.

llvm-svn: 75875

(although we don't get a very good error message).

llvm-svn: 75864

llvm-svn: 75863

llvm-svn: 75862

This extra check is not trigged when runnning "make check" on top-of-tree.

Change error message to better match llvm_unreachable() grammar.

Don't call llvm_unreachable() when writing error messages to a file, but keep going.

llvm-svn: 75860

 - No functionality change.

llvm-svn: 75859

 - No intended functionality change.

llvm-svn: 75848

Reserved registers are not candidates for scavenging, and they were removed
from the candidate list like this:

CreateRegClassMask(RC, Candidates);
Candidates ^= ReservedRegs;

However, when there are reserved registers outside RC, this causes invalid
bits to be set in Candidates.

llvm-svn: 75847

llvm-svn: 75840

llvm-svn: 75838

llvm-svn: 75831

we care more about random access than insertion/deletion of elements.

llvm-svn: 75828

llvm-svn: 75742

llvm-svn: 75703

Have asm printers use formatted_raw_ostream directly to avoid a
dynamic_cast<>.

llvm-svn: 75670

additional bug fixes:

1. The bug that everyone hit was a problem in the asmprinter where it
   would remove $stub but keep the L prefix on a name when emitting the
   indirect symbol.  This is easy to fix by keeping the name of the stub
   and the name of the symbol in a StringMap instead of just keeping a
   StringSet and trying to reconstruct it late.

2. There was a problem printing the personality function.  The current
   logic to print out the personality function from the DWARF information
   is a bit of a cesspool right now that duplicates a bunch of other 
   logic in the asm printer.  The short version of it is that it depends
   on emitting both the L and _ prefix for symbols (at least on darwin)
   and until I can untangle it, it is best to switch the mangler back to
   emitting both prefixes.

llvm-svn: 75646

This adds location info for all llvm_unreachable calls (which is a macro now) in
!NDEBUG builds.
In NDEBUG builds location info and the message is off (it only prints
"UREACHABLE executed").

llvm-svn: 75640

--- Reverse-merging r75619 into '.':
U    lib/Target/DarwinTargetAsmInfo.cpp
U    lib/CodeGen/AsmPrinter/AsmPrinter.cpp
--- Reverse-merging r75618 into '.':
U    lib/CodeGen/ELFWriter.cpp
U    lib/CodeGen/MachOCodeEmitter.cpp
U    lib/CodeGen/MachOWriter.cpp
--- Reverse-merging r75617 into '.':
U    lib/Target/CBackend/CBackend.cpp
--- Reverse-merging r75616 into '.':
U    tools/bugpoint/Miscompilation.cpp
U    tools/lto/LTOCodeGenerator.cpp
U    tools/lto/LTOModule.cpp

llvm-svn: 75638

llvm-svn: 75630

dubious looking things that I need to investigate in more detail.

llvm-svn: 75619

llvm-svn: 75618

indicates whether the label is private or not, instead of taking
prefix stuff.  One effect of this is that symbols will be generated
with *just* the private prefix, instead of both the private prefix
*and* the user-label-prefix, but this doesn't matter as long as it
is consistent.  For example we'll now get "Lfoo" instead of "L_foo".
These are just assembler temporary labels anyway, so they never even
make it into the .o file.

llvm-svn: 75607