semantically identical, but little difference in
either results or execution speed; but it's much
easier to read, at least IMO.

llvm-svn: 50999

llvm-svn: 50991

llvm-svn: 50990

This is necessary to unbreak the build.

llvm-svn: 50988

possible for it to produce worse code than before.

The rest of this patch is code cleanup.

llvm-svn: 50987

llvm-svn: 50967

If all sources of a PHI node are defined by an implicit_def, just emit an implicit_def instead of a copy.

llvm-svn: 50927

 - Comment fixes.
 - Moar whitespace.
 - Made ivars "private" by default.
No functionality change.

llvm-svn: 50926

no functional change.

llvm-svn: 50921

case where there are multiple blocks with a large
number of common tail instructions more efficiently
(compile time optimization).

llvm-svn: 50916

Darwin.  This is a hack of course, but it does
at least look at the right thing: gotpcrel means
that this is already an offset, so an explicit
offset is not needed (and wrong).  I think this
is good enough for the moment: Anton is working
on something better.

llvm-svn: 50850

llvm-svn: 50836

on x86-64 linux.  This causes no regressions on
32 bit linux and 32 bit ppc.  More tests pass
on 64 bit ppc with no regressions.  I didn't
turn on eh on 64 bit linux because the intrinsics
needed to compile the eh runtime aren't done
yet.  But if you turn it on and link with the
mainline runtime then eh seems to work fine
on x86-64 linux with this patch.  Thanks to
Dale for testing.  The main point of the patch
is that if you output that some object is
encoded using 4 bytes you had better not output
8 bytes for it: the patch makes everything
consistent.

llvm-svn: 50825

%ecx = op
store %cl<kill>, (addr)
(addr) = op %al

It's not safe to unfold the last operand and eliminate store even though %cl is marked kill. It's a sub-register use which means one of its super-register(s) may be used below.

llvm-svn: 50794

llvm-svn: 50793

llvm-svn: 50775

llvm-svn: 50696

llvm-svn: 50695

ComputeMaskedBits handles, just use a 'default:'. This avoids
TargetLowering's list getting out of date with SelectionDAG's.

llvm-svn: 50693

ComputeMaskedBits.

llvm-svn: 50692

llvm-svn: 50687

llvm-svn: 50663

ELF headers. The ELF writer still isn't generally usable though.

llvm-svn: 50652

the code being generated does not require an executable stack.

Also, add target-specific code to make use of this on Linux
on x86. 

llvm-svn: 50634

llvm-svn: 50591

llvm-svn: 50562

llvm-svn: 50561

llvm-svn: 50558

ffastmath mode.  This fixes rdar://5902801, a miscompilation
of gcc.dg/builtins-8.c.

Bill, please pull this into Tak.

llvm-svn: 50523

Move platform independent code (lowering of possibly overwritten
arguments, check for tail call optimization eligibility) from
target X86ISelectionLowering.cpp to TargetLowering.h and
SelectionDAGISel.cpp.

Initial PowerPC tail call implementation:

Support ppc32 implemented and tested (passes my tests and
test-suite llvm-test).  
Support ppc64 implemented and half tested (passes my tests).
On ppc tail call optimization is performed if 
  caller and callee are fastcc
  call is a tail call (in tail call position, call followed by ret)
  no variable argument lists or byval arguments
  option -tailcallopt is enabled
Supported:
 * non pic tail calls on linux/darwin
 * module-local tail calls on linux(PIC/GOT)/darwin(PIC)
 * inter-module tail calls on darwin(PIC)
If constraints are not met a normal call will be emitted.

A test checking the argument lowering behaviour on x86-64 was added.

llvm-svn: 50477

llvm-svn: 50463

DAG.UpdateNodeOperands() is called before (not after) the call to
TLI.LowerOperation().

llvm-svn: 50461

targets.

llvm-svn: 50451

This removes the existing bottleneck related to the removal of elements from 
the middle of the queue.

Also fixes a subtle bug in ScheduleDAGRRList::CapturePred:
It was updating the state of the SUnit before removing it. As a result, the
comparison operators were working incorrectly and this SUnit could not be removed 
from the queue properly.

Reviewed by Evan and Dan. Approved by Dan.

llvm-svn: 50412

We now compile test2/test3 to:

_test2:
	## InlineAsm Start
	set %xmm0, %xmm1
	## InlineAsm End
	addps	%xmm1, %xmm0
	ret
_test3:
	## InlineAsm Start
	set %xmm0, %xmm1
	## InlineAsm End
	paddd	%xmm1, %xmm0
	ret

as expected.

llvm-svn: 50389

towards PR2094.  It now compiles the attached .ll file to:

_sad16_sse2:
	movslq	%ecx, %rax
	## InlineAsm Start
	%ecx %rdx %rax %rax %r8d %rdx %rsi
	## InlineAsm End
	## InlineAsm Start
	set %eax
	## InlineAsm End
	ret

which is pretty decent for a 3 output, 4 input asm.

llvm-svn: 50386

e.g.
vr1024<2> extract_subreg vr1025, 2
If vr1024 do not have the same register class as vr1025, it's not safe to coalesce this away. For example, vr1024 might be a GPR32 while vr1025 might be a GPR64.

llvm-svn: 50385

Fix a bug in RegsForValue::getCopyToRegs() that causes cyclical scheduling units. If it's creating multiple CopyToReg nodes that are "flagged" together, it should not create a TokenFactor for it's chain outputs:

c1, f1 = CopyToReg                                                                                                                                                                                             
c2, f2 = CopyToReg                                                                                                                                                                                             
c3     = TokenFactor c1, c2                                                                                                                                                                                    
 ...                                                                                                                                                                                                                      
       = user c3, ..., f2

Now that the two CopyToReg's and the user are "flagged" together. They effectively forms a single scheduling unit. The TokenFactor is now both an operand and a successor of the Flagged nodes.

llvm-svn: 50376

if the zext is not legal.

llvm-svn: 50368

llvm-svn: 50367