| Commit message (Collapse) | Author | Age | Files | Lines | 
| | 
| 
| 
| 
| 
| 
|  | 
fixes CodeGen/PowerPC/2008-06-19-LegalizerCrash.ll
when using the new LegalizeTypes infrastructure.
llvm-svn: 52903
 | 
| | 
| 
| 
| 
| 
| 
|  | 
wrong for types like x86 long double and i1, but
no worse than what is done in LegalizeDAG.
llvm-svn: 52898
 | 
| | 
| 
| 
|  | 
llvm-svn: 52895
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
it impossible to create a MERGE_VALUES node with
only one result: sometimes it is useful to be able
to create a node with only one result out of one of
the results of a node with more than one result, for
example because the new node will eventually be used
to replace a one-result node using ReplaceAllUsesWith,
cf X86TargetLowering::ExpandFP_TO_SINT.  On the other
hand, most users of MERGE_VALUES don't need this and
for them the optimization was valuable.  So add a new
utility method getMergeValues for creating MERGE_VALUES
nodes which by default performs the optimization.
Change almost everywhere to use getMergeValues (and
tidy some stuff up at the same time).
llvm-svn: 52893
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
empty string for ConstantAggregateZero case which surprises selectiondag.
- Correctly handle memcpy from constant string which is zero-initialized.
llvm-svn: 52891
 | 
| | 
| 
| 
|  | 
llvm-svn: 52887
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
Move GetConstantStringInfo to lib/Analysis. Remove
string output routine from Constant. Update all
callers. Change debug intrinsic api slightly to
accomodate move of routine, these now return values
instead of strings.
This unbreaks llvm-gcc bootstrap.
llvm-svn: 52884
 | 
| | 
| 
| 
|  | 
llvm-svn: 52854
 | 
| | 
| 
| 
| 
| 
| 
|  | 
GetConstantStringInfo.  This will hopefully restore llvm-gcc to 
happy bootstrap land.
llvm-svn: 52851
 | 
| | 
| 
| 
| 
| 
| 
|  | 
information of the original load or store, which is checked to be
at least as good, and possibly better.
llvm-svn: 52849
 | 
| | 
| 
| 
|  | 
llvm-svn: 52841
 | 
| | 
| 
| 
| 
| 
|  | 
match normal naming scheme.
llvm-svn: 52820
 | 
| | 
| 
| 
| 
| 
|  | 
This speeds up a particular testcase from 0.0302s to 0.0222s in LiveVariables.
llvm-svn: 52819
 | 
| | 
| 
| 
| 
| 
|  | 
global is constant already.  No functionality change.
llvm-svn: 52812
 | 
| | 
| 
| 
|  | 
llvm-svn: 52808
 | 
| | 
| 
| 
|  | 
llvm-svn: 52806
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
know that there aren't any.
This speed up LiveVariables on instcombine at -O0 -g from 0.3855s to 0.3503s.  Look for more improvements in this area soon!
llvm-svn: 52804
 | 
| | 
| 
| 
| 
| 
| 
|  | 
- Make sure that we're not recalculating the size of a vector
  that never changes.
llvm-svn: 52803
 | 
| | 
| 
| 
| 
| 
|  | 
some uses of std::vector, where it's return std::vector by value. Yuck!
llvm-svn: 52800
 | 
| | 
| 
| 
| 
| 
|  | 
type legality.  Thanks Duncan!
llvm-svn: 52786
 | 
| | 
| 
| 
|  | 
llvm-svn: 52785
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
<16 x float> is 64-byte aligned (for some reason),
which gets us into the stack realignment code.  The
computation changing FP-relative offsets to SP-relative
was broken, assiging a spill temp to a location
also used for parameter passing.  This
fixes it by rounding up the stack frame to a multiple
of the largest alignment (I concluded it wasn't fixable
without doing this, but I'm not very sure.)
llvm-svn: 52750
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
|  | 
string output routine from Constant. Update all
callers. Change debug intrinsic api slightly to
accomodate move of routine, these now return values
instead of strings.
llvm-svn: 52748
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
change it to sint_to_fp on targets where that is cheaper (and
visaversa of course).  This allows us to compile uint_to_fp to:
_test:
	movl	4(%esp), %eax
	shrl	$23, %eax
	cvtsi2ss	%eax, %xmm0
	movl	8(%esp), %eax
	movss	%xmm0, (%eax)
	ret
instead of:
	.align	3
LCPI1_0:					##  double
	.long	0	## double least significant word 4.5036e+15
	.long	1127219200	## double most significant word 4.5036e+15
	.text
	.align	4,0x90
	.globl	_test
_test:
	subl	$12, %esp
	movl	16(%esp), %eax
	shrl	$23, %eax
	movl	%eax, (%esp)
	movl	$1127219200, 4(%esp)
	movsd	(%esp), %xmm0
	subsd	LCPI1_0, %xmm0
	cvtsd2ss	%xmm0, %xmm0
	movl	20(%esp), %eax
	movss	%xmm0, (%eax)
	addl	$12, %esp
	ret
llvm-svn: 52747
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
the list to find it again later.
This speeds up live intervals from 0.37s to 0.30s on instcombine.
llvm-svn: 52745
 | 
| | 
| 
| 
|  | 
llvm-svn: 52744
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
shift.
- Add a readme entry for a missing vector_shuffle optimization that results in
  awful codegen.
llvm-svn: 52740
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
For this it is convenient to permit floats to
be used with EXTRACT_ELEMENT, so I tweaked
things to allow that.  I also added libcalls
for ppcf128 to i32 forms of FP_TO_XINT, since
they exist in libgcc and this case can certainly
occur (and does occur in the testsuite) - before
the i64 libcall was being used.  Also, the
XINT_TO_FP result seemed to be wrong when
the argument is an i128: the wrong fudge
factor was added (the i32 and i64 cases were
handled directly, but the i128 code fell
through to some generic softening code which
seemed to think it was i64 to f32!).  So I
fixed it by adding a fudge factor that I
found in my breakfast cereal.
llvm-svn: 52739
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
select_cc and friends.  This code could be
factorized a bit but I'm not sure that it's
worth it.
llvm-svn: 52724
 | 
| | 
| 
| 
| 
| 
|  | 
the base SDNode's VTList.
llvm-svn: 52722
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
Added abstract class MemSDNode for any Node that have an associated MemOperand
Changed atomic.lcs => atomic.cmp.swap, atomic.las => atomic.load.add, and
atomic.lss => atomic.load.sub
llvm-svn: 52706
 | 
| | 
| 
| 
|  | 
llvm-svn: 52701
 | 
| | 
| 
| 
|  | 
llvm-svn: 52689
 | 
| | 
| 
| 
| 
| 
|  | 
as a questionable case, but the code isn't actually needed.
llvm-svn: 52657
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
,------.
    |      |
    |      v
    |   t2 = phi ... t1 ...
    |      |
    |      v
    |   t1 = ...
    |  ... = ... t1 ...
    |      |
    `------'
where there is a use in a PHI node that's a predecessor to the defining
block. We don't want to mark all predecessors as having the value "alive" in
this case. Also, the assert was too restrictive and didn't handle this case.
llvm-svn: 52655
 | 
| | 
| 
| 
| 
| 
|  | 
needs arbitrary-element removal.
llvm-svn: 52654
 | 
| | 
| 
| 
| 
| 
|  | 
instruction in the block.
llvm-svn: 52649
 | 
| | 
| 
| 
| 
| 
|  | 
stack coloring is now bug free.
llvm-svn: 52644
 | 
| | 
| 
| 
| 
| 
| 
|  | 
clear() on each iteration. This avoids allocating and deallocating
all of DenseMap's memory on each iteration.
llvm-svn: 52642
 | 
| | 
| 
| 
| 
| 
|  | 
top bit of 'reg' instead. If the top bit is set, than the LiveInterval represents a stack slot live interval.
llvm-svn: 52639
 | 
| | 
| 
| 
|  | 
llvm-svn: 52624
 | 
| | 
| 
| 
| 
| 
| 
|  | 
Bail out with an error if there is no libcall available
for the given size of integer.
llvm-svn: 52622
 | 
| | 
| 
| 
|  | 
llvm-svn: 52621
 | 
| | 
| 
| 
| 
| 
|  | 
stores.
llvm-svn: 52620
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
fixes PR2476; patch by Richard Osborne.  The same
problem exists for a bunch of other operators, but
I'm ignoring this because they will be automagically
fixed when the new LegalizeTypes infrastructure lands,
since it already solves this problem centrally.
llvm-svn: 52610
 | 
| | 
| 
| 
|  | 
llvm-svn: 52604
 | 
| | 
| 
| 
| 
| 
|  | 
check this with an assert.
llvm-svn: 52603
 | 
| | 
| 
| 
|  | 
llvm-svn: 52601
 | 
| | 
| 
| 
|  | 
llvm-svn: 52600
 | 
| | 
| 
| 
|  | 
llvm-svn: 52585
 |