U    test/CodeGen/X86/2009-03-13-PHIElimBug.ll
D    test/CodeGen/X86/2009-03-16-PHIElimInLPad.ll
U    lib/CodeGen/PHIElimination.cpp

r67049 was causing this failure:

Running /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.src/test/CodeGen/X86/dg.exp ...
FAIL: /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.src/test/CodeGen/X86/2009-03-13-PHIElimBug.ll for PR3784
Failed with exit(1) at line 1
while running:  llvm-as < /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvm.src/test/CodeGen/X86/2009-03-13-PHIElimBug.ll |  llc -march=x86 | /usr/bin/grep -A 2 {call f} | /usr/bin/grep movl
child process exited abnormally

llvm-svn: 67051

how invokes are set up.  The fix could be disturbed by
register copies coming after the EH_LABEL, and also didn't
behave quite right when it was the invoke result that
was used in a phi node.  Also (see new testcase) fix
another phi elimination bug while there: register copies
in the landing pad need to come after the EH_LABEL, because
that's where execution branches to when unwinding.  If they
come before the EH_LABEL then they will never be executed...
Also tweak the original testcase so it doesn't use a no-longer
existing counter.
The accumulated phi elimination changes fix two of seven Ada
testsuite failures that turned up after landing pad critical
edge splitting was turned off.  So there's probably more to come.

llvm-svn: 67049

Incorporate Tilmann's 128-bit operation patch. Evidently, it gets the
llvm-gcc bootstrap a bit further along.

llvm-svn: 67048

This causes incorrect stack frame allocation when the last object is an array allocated on the stack which would lead
the compiled program to run over its stack. Thanks to Gil Dogon

llvm-svn: 67034

llvm-svn: 67025

llvm-svn: 67023

useful with it at the moment, but it will in the future.

llvm-svn: 67012

shift constant expressions, and add support for folding vector
shift constant expressions. This fixes PR3802.

llvm-svn: 67010

it has a smaller encoding than absolute addressing.

llvm-svn: 67002

operand is a signed 32-bit immediate. Unlike with the 8-bit
signed immediate case, it isn't actually smaller to fold a
32-bit signed immediate instead of a load. In fact, it's
larger in the case of 32-bit unsigned immediates, because
they can be materialized with movl instead of movq.

llvm-svn: 67001

llvm-svn: 67000

if FPConstant is legal because if the FPConstant doesn't need to be stored
in a constant pool, the transformation is unlikely to be profitable.

llvm-svn: 66994

ptrtoint and inttoptr in X86FastISel. These casts aren't always
handled in the generic FastISel code because X86 sometimes needs
custom code to do truncation and zero-extension.

llvm-svn: 66988

llvm.global.variable's but no llvm.declare's.

llvm-svn: 66977

Fix PR3784: If the source of a phi comes from a bb ended with an invoke, make sure the copy is inserted before the try range (unless it's used as an input to the invoke, then insert it after the last use), not at the end of the bb.

Also re-apply r66140 which was disabled as a workaround.

llvm-svn: 66976

large for the testsuite) took over six minutes to compile on my Mac.
The patched LLVM-GCC compiles that testcase in three seconds (GCC
takes less than one second).  This hash function is more complex
(about 35 instructions on x86) than what Chris wanted, but I expect it
will be well-behaved with arbitrary inputs.

Thank you to everyone who responded to my previous request for advice.

llvm-svn: 66962

mode).

Running /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/test/BugPoint/dg.exp ...
FAIL: /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/test/BugPoint/crash-narrowfunctiontest.ll
Failed with signal(SIGBUS) at line 1
while running: bugpoint /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/test/BugPoint/crash-narrowfunctiontest.ll -bugpoint-crashcalls -silence-passes > /dev/null
0   bugpoint          0x0035dd25 llvm::sys::SetInterruptFunction(void (*)()) + 85
1   bugpoint          0x0035e382 llvm::sys::RemoveFileOnSignal(llvm::sys::Path const&, std::string*) + 706
2   libSystem.B.dylib 0x92f112bb _sigtramp + 43
3   libSystem.B.dylib 0xffffffff _sigtramp + 1829694831
4   bugpoint          0x00021d1c main + 92
5   bugpoint          0x00002106 start + 54
6   bugpoint          0x00000004 start + 18446744073709543220
Stack dump:
0.    Program arguments: bugpoint /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/test/BugPoint/crash-narrowfunctiontest.ll -bugpoint-crashcalls -silence-passes 

FAIL: /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/test/BugPoint/misopt-basictest.ll
Failed with signal(SIGBUS) at line 1
while running: bugpoint /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/test/BugPoint/misopt-basictest.ll -dce -bugpoint-deletecalls -simplifycfg -silence-passes
0   bugpoint          0x0035dd25 llvm::sys::SetInterruptFunction(void (*)()) + 85
1   bugpoint          0x0035e382 llvm::sys::RemoveFileOnSignal(llvm::sys::Path const&, std::string*) + 706
2   libSystem.B.dylib 0x92f112bb _sigtramp + 43
3   libSystem.B.dylib 0xffffffff _sigtramp + 1829694831
4   bugpoint          0x00021d1c main + 92
5   bugpoint          0x00002106 start + 54
6   bugpoint          0x00000006 start + 18446744073709543222
Stack dump:
0.    Program arguments: bugpoint /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/test/BugPoint/misopt-basictest.ll -dce -bugpoint-deletecalls -simplifycfg -silence-passes 

FAIL: /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/test/BugPoint/remove_arguments_test.ll
Failed with signal(SIGBUS) at line 1
while running: bugpoint /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/test/BugPoint/remove_arguments_test.ll  -bugpoint-crashcalls -silence-passes
0   bugpoint          0x0035dd25 llvm::sys::SetInterruptFunction(void (*)()) + 85
1   bugpoint          0x0035e382 llvm::sys::RemoveFileOnSignal(llvm::sys::Path const&, std::string*) + 706
2   libSystem.B.dylib 0x92f112bb _sigtramp + 43
3   libSystem.B.dylib 0xffffffff _sigtramp + 1829694831
4   bugpoint          0x00021d1c main + 92
5   bugpoint          0x00002106 start + 54
Stack dump:
0.    Program arguments: bugpoint /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore/test/BugPoint/remove_arguments_test.ll -bugpoint-crashcalls -silence-passes 

--- Reverse-merging (from foreign repository) r66920 into '.':
U    include/llvm/Support/CallSite.h
U    include/llvm/Instructions.h
U    lib/Analysis/IPA/GlobalsModRef.cpp
U    lib/Analysis/IPA/Andersens.cpp
U    lib/Bitcode/Writer/BitcodeWriter.cpp
U    lib/VMCore/Instructions.cpp
U    lib/VMCore/Verifier.cpp
U    lib/VMCore/AsmWriter.cpp
U    lib/Transforms/Utils/LowerInvoke.cpp
U    lib/Transforms/Scalar/SimplifyCFGPass.cpp
U    lib/Transforms/IPO/PruneEH.cpp
U    lib/Transforms/IPO/DeadArgumentElimination.cpp

llvm-svn: 66953

by inserting explicit zero extensions where necessary. Included
is a testcase where SelectionDAG produces a virtual register
holding an i1 value which FastISel previously mistakenly assumed
to be zero-extended.

llvm-svn: 66941

add a fixme note on how to remove code duplication.

llvm-svn: 66932

llvm-svn: 66930

llvm-svn: 66922

changes.

For InvokeInst now all arguments begin at op_begin().
The Callee, Cont and Fail are now faster to get by
access relative to op_end().

This patch introduces some temporary uglyness in CallSite.
Next I'll bring CallInst up to a similar scheme and then
the uglyness will magically vanish.

This patch also exposes all the reliance of the libraries
on InvokeInst's operand ordering. I am thinking of taking
care of that too.

llvm-svn: 66920

codegen to the same thing as integer truncates to i8 (the top bits are 
just undefined).  This implements rdar://6667338

llvm-svn: 66902

instructions. Prevent that if we don't want implicit uses of SSE.

llvm-svn: 66877

Fix some significant problems with constant pools that resulted in unnecessary paddings between constant pool entries, larger than necessary alignments (e.g. 8 byte alignment for .literal4 sections), and potentially other issues.

1. ConstantPoolSDNode alignment field is log2 value of the alignment requirement. This is not consistent with other SDNode variants.
2. MachineConstantPool alignment field is also a log2 value.
3. However, some places are creating ConstantPoolSDNode with alignment value rather than log2 values. This creates entries with artificially large alignments, e.g. 256 for SSE vector values.
4. Constant pool entry offsets are computed when they are created. However, asm printer group them by sections. That means the offsets are no longer valid. However, asm printer uses them to determine size of padding between entries.
5. Asm printer uses expensive data structure multimap to track constant pool entries by sections.
6. Asm printer iterate over SmallPtrSet when it's emitting constant pool entries. This is non-deterministic.


Solutions:
1. ConstantPoolSDNode alignment field is changed to keep non-log2 value.
2. MachineConstantPool alignment field is also changed to keep non-log2 value.
3. Functions that create ConstantPool nodes are passing in non-log2 alignments.
4. MachineConstantPoolEntry no longer keeps an offset field. It's replaced with an alignment field. Offsets are not computed when constant pool entries are created. They are computed on the fly in asm printer and JIT.
5. Asm printer uses cheaper data structure to group constant pool entries.
6. Asm printer compute entry offsets after grouping is done.
7. Change JIT code to compute entry offsets on the fly.

llvm-svn: 66875

llvm-svn: 66870

for i32/i64 expressions (we could also do i16 on cpus where
i16 lea is fast, but I didn't add this).  On the example, we now
generate:

_test:
	movl	4(%esp), %eax
	cmpl	$42, (%eax)
	setl	%al
	movzbl	%al, %eax
	leal	4(%eax,%eax,8), %eax
	ret

instead of:

_test:
	movl	4(%esp), %eax
	cmpl	$41, (%eax)
	movl	$4, %ecx
	movl	$13, %eax
	cmovg	%ecx, %eax
	ret

llvm-svn: 66869

example to:

_test:
	movl	4(%esp), %eax
	cmpl	$41, (%eax)
	setg	%al
	movzbl	%al, %eax
	orl	$4294967294, %eax
	ret

instead of:

        movl    4(%esp), %eax
        cmpl    $41, (%eax)
	movl	$4294967294, %ecx
	movl	$4294967295, %eax
	cmova	%ecx, %eax
	ret

which is smaller in code size and faster. rdar://6668608

llvm-svn: 66868

llvm-svn: 66867

llvm-svn: 66866

operands can't both be fully folded at the same time. For example,
in the included testcase, a global variable is being added with
an add of two values. The global variable wants RIP-relative
addressing, so it can't share the address with another base
register, but it's still possible to fold the initial add.

llvm-svn: 66865

codegen (speculative execution).

llvm-svn: 66859

llvm-svn: 66850

to the stack.  This shrinks all llvm tools by 9k, and improves reentrancy.

llvm-svn: 66847

llvm-svn: 66845

llvm-svn: 66843

right; did the wrong thing when there are exactly 11
non-debug instructions, followed by debug info.
Remove a FIXME since it's apparently been fixed along the way.

llvm-svn: 66840

in the Ada testcase.  Reverting this only covers up
the real problem, which is a nasty conceptual difficulty
in the phi elimination pass: when eliminating phi nodes
in landing pads, the register copies need to come before
the invoke, not at the end of the basic block which is
too late...  See PR3784.

llvm-svn: 66826

sorting of ConstantInt's; unreinvent wheel.

llvm-svn: 66824

access each with a fixed negative index from op_end().

This has two important implications:
- getUser() will work faster, because there are less iterations
  for the waymarking algorithm to perform. This is important
  when running various analyses that want to determine callers
  of basic blocks.
- getSuccessor() now runs faster, because the indirection via OperandList
  is not necessary: Uses corresponding to the successors are at fixed
  offset to "this".

The price we pay is the slightly more complicated logic in the operator
User::delete, as it has to pick up the information whether it has to free
the memory of an original unconditional BranchInst or a BranchInst that
was originally conditional, but has been shortened to unconditional.
I was not able to come up with a nicer solution to this problem. (And
rest assured, I tried *a lot*).

Similar reorderings will follow for InvokeInst and CallInst. After that
some optimizations to pred_iterator and CallSite will fall out naturally.

llvm-svn: 66815