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

llvm-svn: 66937

llvm-svn: 66936

add a fixme note on how to remove code duplication.

llvm-svn: 66932

llvm-svn: 66930

llvm-svn: 66927

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

llvm-svn: 66918

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

llvm-svn: 66902

errors when thrown.  This gets us nice errors like this from tblgen:

CMOVL32rr: 	(set GR32:i32:$dst, (X86cmov GR32:$src1, GR32:$src2))
/Users/sabre/llvm/Debug/bin/tblgen: error:
Included from X86.td:116:
Parsing X86InstrInfo.td:922: In CMOVL32rr: X86cmov node requires exactly 4 operands!
def CMOVL32rr : I<0x4C, MRMSrcReg,       // if <s, GR32 = GR32
^

instead of just:

CMOVL32rr: 	(set GR32:i32:$dst, (X86cmov GR32:$src1, GR32:$src2))
/Users/sabre/llvm/Debug/bin/tblgen: In CMOVL32rr: X86cmov node requires exactly 4 operands!

This is all I plan to do with this, but it should be easy enough to improve if anyone 
cares (e.g. keeping more loc info in "dag" expr records in tblgen.

llvm-svn: 66898

llvm-svn: 66897

llvm-svn: 66895

llvm-svn: 66890

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

llvm-svn: 66877

llvm-svn: 66876

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: 66874

lexer into its own TGSourceMgr class.

llvm-svn: 66873

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

llvm-svn: 66839

llvm-svn: 66838

single character writes.

llvm-svn: 66827

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

llvm-svn: 66825

sorting of ConstantInt's; unreinvent wheel.

llvm-svn: 66824

refers to the "prefix" directory, i.e., one level above "bin".  LLVMGCCPATH
is used as the directory containing the llvm-gcc executable, so add a "/bin"
suffix to get from LLVMGCCDIR to LLVMGCCPATH.

llvm-svn: 66823

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

Re-apply 66024 with fixes: 1. Fixed indirect call to immediate address assembly. 2. Fixed JIT encoding by making the address pc-relative.

llvm-svn: 66803