| Commit message (Collapse) | Author | Age | Files | Lines | 
| ... |  | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
address of the PassInfo directly instead of calling getPassInfo.
This eliminates a bunch of dynamic initializations of static data.
Also, fold RegisterPassBase into PassInfo, make a bunch of its
data members const, and rearrange some code to initialize data
members in constructors instead of using setter member functions.
llvm-svn: 51022
 | 
| | 
| 
| 
| 
| 
| 
|  | 
several things that were neither in an anonymous namespace nor static
but not intended to be global.
llvm-svn: 51017
 | 
| | 
| 
| 
| 
| 
|  | 
Teach X86 a few more vsetcc patterns.  Custom lowering for unsupported ones is next.
llvm-svn: 51009
 | 
| | 
| 
| 
| 
| 
|  | 
locations are at the right offset from each other.
llvm-svn: 51008
 | 
| | 
| 
| 
| 
| 
| 
|  | 
if those blocks consist entirely of common instructions;
merging will not add an extra branch in this case.
llvm-svn: 51006
 | 
| | 
| 
| 
| 
| 
|  | 
changes that don't change functionality.
llvm-svn: 51004
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
semantically identical, but little difference in
either results or execution speed; but it's much
easier to read, at least IMO.
llvm-svn: 50999
 | 
| | 
| 
| 
| 
| 
|  | 
make use of it.
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
 | 
| | 
| 
| 
| 
| 
|  | 
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
 | 
| | 
| 
| 
| 
| 
|  | 
instead?)
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
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
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
 | 
| | 
| 
| 
| 
| 
|  | 
aggregate types.
llvm-svn: 50366
 | 
| | 
| 
| 
| 
| 
|  | 
reorder some of the members for clarity.
llvm-svn: 50365
 | 
| | 
| 
| 
|  | 
llvm-svn: 50361
 | 
| | 
| 
| 
| 
| 
| 
|  | 
memcpy/memset expansion. It was a bug for the SVOffset value
to be used in the actual address calculations.
llvm-svn: 50359
 |