llvm-svn: 76702

be useful, and it's currently unused.  (Some issues: it isn't actually 
rich enough to capture the semantics on many architectures, and
semantics can vary depending on the type being shifted.)

llvm-svn: 76633

llvm-svn: 76598

llvm-svn: 76553

Is this really a winning transformation?
fold (shl (srl x, c1), c2) -> (shl (and x, (shl -1, c1)), (sub c2, c1)) or                                                                              
                              (srl (and x, (shl -1, c1)), (sub c1, c2))

llvm-svn: 76535

llvm-svn: 76533

to a place where it affects everything.  Occurs
only on calls AFAIK.

llvm-svn: 76502

llvm-svn: 76356

llvm-svn: 76153

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

llvm-svn: 76097

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

llvm-svn: 76089

llvm-svn: 75925

llvm-svn: 75840

llvm-svn: 75831

llvm-svn: 75703

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

Begin the painful process of tearing apart the rat'ss nest that is Constants.cpp and ConstantFold.cpp.
This involves temporarily hard wiring some parts to use the global context.  This isn't ideal, but it's
the only way I could figure out to make this process vaguely incremental.

llvm-svn: 75445

implemented in codegen, have no frontend to generate them, and are 
better implemented with pattern matching (like the ppc backend does
to generate rlwimi/rlwinm etc).

PR4543

llvm-svn: 75430

llvm-svn: 75423

The blackfin processor has a legal i16 type, but only logic operations on i32.

llvm-svn: 75419

llvm-svn: 75418

Make llvm_unreachable take an optional string, thus moving the cerr<< out of
line.
LLVM_UNREACHABLE is now a simple wrapper that makes the message go away for
NDEBUG builds.

llvm-svn: 75379

and abort()/exit() -> llvm_report_error().

llvm-svn: 75363

Fix up support for OptionalDefOperand when it defaults to an actual register def. I need this to get ready for major Thumb1 surgery.

llvm-svn: 75328

llvm-svn: 75320

llvm-svn: 75197

value.  Adjust other code to deal with that correctly.  Make 
DAGTypeLegalizer::PromoteIntRes_EXTRACT_VECTOR_ELT take advantage of 
this new flexibility to simplify the code and make it deal with unusual 
vectors (like <4 x i1>) correctly.  Fixes PR3037.

llvm-svn: 75176

llvm-svn: 75161

llvm-svn: 75153

nodes with operand types that differ from the result type. (This
doesn't normally happen right now, because
SelectionDAGLowering::visitShuffleVector normalizes vector shuffles.)

llvm-svn: 75081

llvm-svn: 75067

number of elements.  Make some simplifications based
on this (in particular SplitVecRes_SETCC).  Tighten
up some checking while there.

llvm-svn: 75050

and cases alphabetically.  No functionality change.

llvm-svn: 75001

these instructions, no autoupgrade or backwards compatibility support is
provided.

llvm-svn: 74991

VSETCC must define all bits, which is different than it was documented
to before.  Since all targets that implement VSETCC already have this
behavior, and we don't optimize based on this, just change the 
documentation.  We now get nice code for vec_compare.ll

llvm-svn: 74978

for now, conservatively return false.

llvm-svn: 74969

as "X" constraint and "P" modifier on x86.  Make this work.
(Change may not be sufficient to fix it for non-Darwin, but
I'm pretty sure it won't break anything.)
gcc.apple/asm-block-32.c
gcc.apple/asm-block-33.c

llvm-svn: 74967

the input is legal (4 x i32)

llvm-svn: 74964

llvm-svn: 74962