analysis, one that does the xform.

llvm-svn: 82443

llvm-svn: 82442

assert if the setModuleInfo hasn't been called.

llvm-svn: 82441

llvm-svn: 82440

from a piece of a large store when both are in the same block.

This allows clang to compile the testcase in PR4216 to this code:

_test_bitfield:
	movl	4(%esp), %eax
	movl	%eax, %ecx
	andl	$-65536, %ecx
	orl	$32962, %eax
	andl	$40186, %eax
	orl	%ecx, %eax
	ret

This is not ideal, but is a whole lot better than the code produced
by llvm-gcc:

_test_bitfield:
	movw	$-32574, %ax
	orw	4(%esp), %ax
	andw	$-25350, %ax
	movw	%ax, 4(%esp)
	movw	7(%esp), %cx
	shlw	$8, %cx
	movzbl	6(%esp), %edx
	orw	%cx, %dx
	movzwl	%dx, %ecx
	shll	$16, %ecx
	movzwl	%ax, %eax
	orl	%ecx, %eax
	ret

and dramatically better than that produced by gcc 4.2:

_test_bitfield:
	pushl	%ebx
	call	L3
"L00000000001$pb":
L3:
	popl	%ebx
	movl	8(%esp), %eax
	leal	0(,%eax,4), %edx
	sarb	$7, %dl
	movl	%eax, %ecx
	andl	$7168, %ecx
	andl	$-7201, %ebx
	movzbl	%dl, %edx
	andl	$1, %edx
	sall	$5, %edx
	orl	%ecx, %ebx
	orl	%edx, %ebx
	andl	$24, %eax
	andl	$-58336, %ebx
	orl	%eax, %ebx
	orl	$32962, %ebx
	movl	%ebx, %eax
	popl	%ebx
	ret

llvm-svn: 82439

llvm-svn: 82438

Fix PR4986. "r1024 = insert_subreg r1024, undef, 2" cannot be turned in an implicit_def. Instead, it's an identity copy so it should be eliminated. Also make sure to update livevariable kill information.

llvm-svn: 82436

is.
 - The problem is that formatted_ostream forces its underlying buffer to be
   unbuffered, so if some client happens to wrap a formatted_ostream around
   something, but still use the underlying stream, then we can end up writing on
   a fully unbuffered output (which was never intended to be unbuffered).

 - This makes clang (and presumably llvm-gcc) -emit-llvm -S a mere 10x faster.

llvm-svn: 82434

llvm-svn: 82427

llvm-svn: 82426

llvm-svn: 82425

; CHECK: foo
; CHECK-NOT: foo
; CHECK: bar

would always fail.

llvm-svn: 82424

run if appropriate target is supported.

llvm-svn: 82419

feature, either build the JIT in debug mode to enable it by default or pass
-jit-emit-debug to lli.

Right now, the only debug information that this communicates to GDB is call
frame information, since it's already being generated to support exceptions in
the JIT.  Eventually, when DWARF generation isn't tied so tightly to AsmPrinter,
it will be easy to push that information to GDB through this interface.

Here's a step-by-step breakdown of how the feature works:

- The JIT generates the machine code and DWARF call frame info
  (.eh_frame/.debug_frame) for a function into memory.
- The JIT copies that info into an in-memory ELF file with a symbol for the
  function.
- The JIT creates a code entry pointing to the ELF buffer and adds it to a
  linked list hanging off of a global descriptor at a special symbol that GDB
  knows about.
- The JIT calls a function marked noinline that GDB knows about and has put an
  internal breakpoint in.
- GDB catches the breakpoint and reads the global descriptor to look for new
  code.
- When sees there is new code, it reads the ELF from the inferior's memory and
  adds it to itself as an object file.
- The JIT continues, and the next time we stop the program, we are able to
  produce a proper backtrace.

Consider running the following program through the JIT:

#include <stdio.h>
void baz(short z) {
  long w = z + 1;
  printf("%d, %x\n", w, *((int*)NULL));  // SEGFAULT here
}
void bar(short y) {
  int z = y + 1;
  baz(z);
}
void foo(char x) {
  short y = x + 1;
  bar(y);
}
int main(int argc, char** argv) {
  char x = 1;
  foo(x);
}

Here is a backtrace before this patch:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x2aaaabdfbd10 (LWP 25476)]
0x00002aaaabe7d1a8 in ?? ()
(gdb) bt
#0  0x00002aaaabe7d1a8 in ?? ()
#1  0x0000000000000003 in ?? ()
#2  0x0000000000000004 in ?? ()
#3  0x00032aaaabe7cfd0 in ?? ()
#4  0x00002aaaabe7d12c in ?? ()
#5  0x00022aaa00000003 in ?? ()
#6  0x00002aaaabe7d0aa in ?? ()
#7  0x01000002abe7cff0 in ?? ()
#8  0x00002aaaabe7d02c in ?? ()
#9  0x0100000000000001 in ?? ()
#10 0x00000000014388e0 in ?? ()
#11 0x00007fff00000001 in ?? ()
#12 0x0000000000b870a2 in llvm::JIT::runFunction (this=0x1405b70,
F=0x14024e0, ArgValues=@0x7fffffffe050)
   at /home/rnk/llvm-gdb/lib/ExecutionEngine/JIT/JIT.cpp:395
#13 0x0000000000baa4c5 in llvm::ExecutionEngine::runFunctionAsMain
(this=0x1405b70, Fn=0x14024e0, argv=@0x13f06f8, envp=0x7fffffffe3b0)
   at /home/rnk/llvm-gdb/lib/ExecutionEngine/ExecutionEngine.cpp:377
#14 0x00000000007ebd52 in main (argc=2, argv=0x7fffffffe398,
envp=0x7fffffffe3b0) at /home/rnk/llvm-gdb/tools/lli/lli.cpp:208

And a backtrace after this patch:
Program received signal SIGSEGV, Segmentation fault.
0x00002aaaabe7d1a8 in baz ()
(gdb) bt
#0  0x00002aaaabe7d1a8 in baz ()
#1  0x00002aaaabe7d12c in bar ()
#2  0x00002aaaabe7d0aa in foo ()
#3  0x00002aaaabe7d02c in main ()
#4  0x0000000000b870a2 in llvm::JIT::runFunction (this=0x1405b70,
F=0x14024e0, ArgValues=...)
   at /home/rnk/llvm-gdb/lib/ExecutionEngine/JIT/JIT.cpp:395
#5  0x0000000000baa4c5 in llvm::ExecutionEngine::runFunctionAsMain
(this=0x1405b70, Fn=0x14024e0, argv=..., envp=0x7fffffffe3c0)
   at /home/rnk/llvm-gdb/lib/ExecutionEngine/ExecutionEngine.cpp:377
#6  0x00000000007ebd52 in main (argc=2, argv=0x7fffffffe3a8,
envp=0x7fffffffe3c0) at /home/rnk/llvm-gdb/tools/lli/lli.cpp:208

llvm-svn: 82418

llvm-svn: 82416

llvm-svn: 82415

llvm-svn: 82414

llvm-svn: 82413

llvm-svn: 82412

scary, as it indicates a lurking bug. yay.

llvm-svn: 82411

llvm-svn: 82410

llvm-svn: 82409

llvm-svn: 82408

llvm-svn: 82407

early for the stated reasons: this allows it to find more 
equivalences and depend less on code layout.

llvm-svn: 82404

so that nonlocal and partially redundant loads can use it as well.
The testcase shows examples of craziness this can handle.  This triggers
*many* times in 176.gcc.

llvm-svn: 82403

more generic.

llvm-svn: 82402

llvm-svn: 82400

(and load -> load) when the base pointers must alias but when
they are different types.  This occurs very very frequently in
176.gcc and other code that uses bitfields a lot.

llvm-svn: 82399

llvm-svn: 82398

llvm-svn: 82397

U    lib/CodeGen/AsmPrinter/DwarfException.cpp
U    lib/CodeGen/AsmPrinter/DwarfException.h

--- Reverse-merging r82274 into '.':
U    lib/Target/TargetLoweringObjectFile.cpp
G    lib/CodeGen/AsmPrinter/DwarfException.cpp

These revisions were breaking everything.

llvm-svn: 82396

llvm-svn: 82395

llvm-svn: 82394

llvm-svn: 82393

llvm-svn: 82392

llvm-svn: 82391

llvm-svn: 82390

llvm-svn: 82389

the MachineInstr ->MCInst lowering process, not in the 
asmprinter.

llvm-svn: 82388