6502/llvm-6502
1
0
Fork 0
mirror of https://github.com/c64scene-ar/llvm-6502.git synced 2024-08-08 19:29:45 +00:00
Code Issues Projects Releases Wiki Activity
47,824 Commits 39 Branches 0 Tags 277 MiB
38a253ddf7
Commit Graph

78 Commits

Author SHA1 Message Date
Duncan Sands
7d0d846064 LegalizeTypes support for INSERT_VECTOR_ELT with 
a non-constant index.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52292 91177308-0d34-0410-b5e6-96231b3b80d8
 2008-06-15 20:00:14 +00:00
Duncan Sands
edfcf598fa Sometimes (rarely) nodes held in LegalizeTypes 
maps can be deleted.  This happens when RAUW
replaces a node N with another equivalent node
E, deleting the first node.  Solve this by
adding (N, E) to ReplacedNodes, which is already
used to remap nodes to replacements.  This means
that deleted nodes are being allowed in maps,
which can be delicate: the memory may be reused
for a new node which might get confused with the
old deleted node pointer hanging around in the
maps, so detect this and flush out maps if it
occurs (ExpungeNode).  The expunging operation
is expensive, however it never occurs during
a llvm-gcc bootstrap or anywhere in the nightly
testsuite.  It occurs three times in "make check":
Alpha/illegal-element-type.ll,
PowerPC/illegal-element-type.ll and
X86/mmx-shift.ll.  If expunging proves to be too
expensive then there are other more complicated
ways of solving the problem.
In the normal case this patch adds the overhead
of a few more map lookups, which is hopefully
negligable.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52214 91177308-0d34-0410-b5e6-96231b3b80d8
 2008-06-11 11:42:12 +00:00
Duncan Sands
83ec4b6711 Wrap MVT::ValueType in a struct to get type safety 
and better control the abstraction.  Rename the type
to MVT.  To update out-of-tree patches, the main
thing to do is to rename MVT::ValueType to MVT, and
rewrite expressions like MVT::getSizeInBits(VT) in
the form VT.getSizeInBits().  Use VT.getSimpleVT()
to extract a MVT::SimpleValueType for use in switch
statements (you will get an assert failure if VT is
an extended value type - these shouldn't exist after
type legalization).
This results in a small speedup of codegen and no
new testsuite failures (x86-64 linux).


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52044 91177308-0d34-0410-b5e6-96231b3b80d8
 2008-06-06 12:08:01 +00:00
Duncan Sands
41edfb8ae1 Provide an explicit list of operands to MakeLibcall, 
rather than having it suck them out of a node.  Add
a bunch of new libcalls, and remove dead softfloat
code (dead, because FloatToInt is used not Expand
in this case).  Note that indexed stores probably
aren't handled properly, likewise for loads.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@49915 91177308-0d34-0410-b5e6-96231b3b80d8
 2008-04-18 20:25:14 +00:00
Roman Levenstein
9cac5259fe Ongoing work on improving the instruction selection infrastructure: 
Rename SDOperandImpl back to SDOperand.
Introduce the SDUse class that represents a use of the SDNode referred by
an SDOperand. Now it is more similar to Use/Value classes.

Patch is approved by Dan Gohman.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@49795 91177308-0d34-0410-b5e6-96231b3b80d8
 2008-04-16 16:15:27 +00:00
Duncan Sands
ddc016cc85 Initial libcall support for LegalizeTypes. This is 
much simpler than in LegalizeDAG because calls are
not yet expanded into call sequences: that happens
after type legalization has finished.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@49634 91177308-0d34-0410-b5e6-96231b3b80d8
 2008-04-14 06:48:48 +00:00
Duncan Sands
4a6da60787 LegalizeTypes can sometimes have deleted nodes 
in its maps.  Add some sanity checks that catch
this kind of thing.  Hopefully these can be
removed one day (once all problems are fixed!)
but for the moment it seems wise to have them in.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@49612 91177308-0d34-0410-b5e6-96231b3b80d8
 2008-04-13 16:04:03 +00:00
Dan Gohman
707e018423 Drop ISD::MEMSET, ISD::MEMMOVE, and ISD::MEMCPY, which are not Legal 
on any current target and aren't optimized in DAGCombiner. Instead
of using intermediate nodes, expand the operations, choosing between
simple loads/stores, target-specific code, and library calls,
immediately.

Previously, the code to emit optimized code for these operations
was only used at initial SelectionDAG construction time; now it is
used at all times. This fixes some cases where rep;movs was being
used for small copies where simple loads/stores would be better.

This also cleans up code that checks for alignments less than 4;
let the targets make that decision instead of doing it in
target-independent code. This allows x86 to use rep;movs in
low-alignment cases.

Also, this fixes a bug that resulted in the use of rep;stos for
memsets of 0 with non-constant memory size when the alignment was
at least 4. It's better to use the library in this case, which
can be significantly faster when the size is large.

This also preserves more SourceValue information when memory
intrinsics are lowered into simple loads/stores.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@49572 91177308-0d34-0410-b5e6-96231b3b80d8
 2008-04-12 04:36:06 +00:00
Roman Levenstein
dc1adac582 Re-commit of the r48822, where the infinite looping problem discovered 
by Dan Gohman is fixed.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@49330 91177308-0d34-0410-b5e6-96231b3b80d8
 2008-04-07 10:06:32 +00:00
Evan Cheng
6397c64441 Backing out 48222 temporarily. 
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@49124 91177308-0d34-0410-b5e6-96231b3b80d8
 2008-04-03 03:13:16 +00:00
Roman Levenstein
e326332acd Use a linked data structure for the uses lists of an SDNode, just like 
LLVM Value/Use does and MachineRegisterInfo/MachineOperand does.
This allows constant time for all uses list maintenance operations.

The idea was suggested by Chris. Reviewed by Evan and Dan.
Patch is tested and approved by Dan.

On normal use-cases compilation speed is not affected. On very big basic
blocks there are compilation speedups in the range of 15-20% or even better. 



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@48822 91177308-0d34-0410-b5e6-96231b3b80d8
 2008-03-26 12:39:26 +00:00
Duncan Sands
d8742eeb2f Initial soft-float support for LegalizeTypes. I rewrote 
the fcopysign expansion from LegalizeDAG to get rid of
what seems to be a bug: the use of sign extension means
that when copying the sign bit from an f32 to an f64,
the upper 32 bits of the f64 (now an i64) are set, not
just the top bit...  I also generalized it to work for
any sized floating point types, and removed the bogosity:
  SDOperand Mask1 = (SrcVT == MVT::f64)
    ? DAG.getConstantFP(BitsToDouble(1ULL << 63), SrcVT)
    : DAG.getConstantFP(BitsToFloat(1U << 31), SrcVT);
  Mask1 = DAG.getNode(ISD::BIT_CONVERT, SrcNVT, Mask1);
(here SrcNVT is an integer with the same size as SrcVT).
As far as I can see this takes a 1 << 63, converts to
a double, converts that to a floating point constant
then converts that to an integer constant, ending up
with... 1 << 63 as an integer constant!  So I just
generate this integer constant directly.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@48305 91177308-0d34-0410-b5e6-96231b3b80d8
 2008-03-12 21:27:04 +00:00
Duncan Sands
ac7613a326 Some LegalizeTypes code factorization and minor 
enhancements.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@48215 91177308-0d34-0410-b5e6-96231b3b80d8
 2008-03-11 06:41:14 +00:00
Duncan Sands
077f9b20d0 LegalizeTypes support for EXTRACT_VECTOR_ELT. The 
approach taken is different to that in LegalizeDAG
when it is a question of expanding or promoting the
result type: for example, if extracting an i64 from
a <2 x i64>, when i64 needs expanding, it bitcasts
the vector to <4 x i32>, extracts the appropriate
two i32's, and uses those for the Lo and Hi parts.
Likewise, when extracting an i16 from a <4 x i16>,
and i16 needs promoting, it bitcasts the vector to
<2 x i32>, extracts the appropriate i32, twiddles
the bits if necessary, and uses that as the promoted
value.  This puts more pressure on bitcast legalization,
and I've added the appropriate cases.  They needed to
be added anyway since users can generate such bitcasts
too if they want to.  Also, when considering various
cases (Legal, Promote, Expand, Scalarize, Split) it is
a pain that expand can correspond to Expand, Scalarize
or Split, so I've changed the LegalizeTypes enum so it
lists those different cases - now Expand only means
splitting a scalar in two.
The code produced is the same as by LegalizeDAG for
all relevant testcases, except for
2007-10-31-extractelement-i64.ll, where the code seems
to have improved (see below; can an expert please tell
me if it is better or not).
Before < vs after >.

<       subl    $92, %esp
<       movaps  %xmm0, 64(%esp)
<       movaps  %xmm0, (%esp)
<       movl    4(%esp), %eax
<       movl    %eax, 28(%esp)
<       movl    (%esp), %eax
<       movl    %eax, 24(%esp)
<       movq    24(%esp), %mm0
<       movq    %mm0, 56(%esp)
---
>       subl    $44, %esp
>       movaps  %xmm0, 16(%esp)
>       pshufd  $1, %xmm0, %xmm1
>       movd    %xmm1, 4(%esp)
>       movd    %xmm0, (%esp)
>       movq    (%esp), %mm0
>       movq    %mm0, 8(%esp)

<       subl    $92, %esp
<       movaps  %xmm0, 64(%esp)
<       movaps  %xmm0, (%esp)
<       movl    12(%esp), %eax
<       movl    %eax, 28(%esp)
<       movl    8(%esp), %eax
<       movl    %eax, 24(%esp)
<       movq    24(%esp), %mm0
<       movq    %mm0, 56(%esp)
---
>       subl    $44, %esp
>       movaps  %xmm0, 16(%esp)
>       pshufd  $3, %xmm0, %xmm1
>       movd    %xmm1, 4(%esp)
>       movhlps %xmm0, %xmm0
>       movd    %xmm0, (%esp)
>       movq    (%esp), %mm0
>       movq    %mm0, 8(%esp)

<       subl    $92, %esp
<       movaps  %xmm0, 64(%esp)
---
>       subl    $44, %esp

<       movl    16(%esp), %eax
<       movl    %eax, 48(%esp)
<       movl    20(%esp), %eax
<       movl    %eax, 52(%esp)
<       movaps  %xmm0, (%esp)
<       movl    4(%esp), %eax
<       movl    %eax, 60(%esp)
<       movl    (%esp), %eax
<       movl    %eax, 56(%esp)
---
>       pshufd  $1, %xmm0, %xmm1
>       movd    %xmm1, 4(%esp)
>       movd    %xmm0, (%esp)
>       movd    %xmm1, 12(%esp)
>       movd    %xmm0, 8(%esp)

<       subl    $92, %esp
<       movaps  %xmm0, 64(%esp)
---
>       subl    $44, %esp

<       movl    24(%esp), %eax
<       movl    %eax, 48(%esp)
<       movl    28(%esp), %eax
<       movl    %eax, 52(%esp)
<       movaps  %xmm0, (%esp)
<       movl    12(%esp), %eax
<       movl    %eax, 60(%esp)
<       movl    8(%esp), %eax
<       movl    %eax, 56(%esp)
---
>       pshufd  $3, %xmm0, %xmm1
>       movd    %xmm1, 4(%esp)
>       movhlps %xmm0, %xmm0
>       movd    %xmm0, (%esp)
>       movd    %xmm1, 12(%esp)
>       movd    %xmm0, 8(%esp)


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@47672 91177308-0d34-0410-b5e6-96231b3b80d8
 2008-02-27 13:34:40 +00:00
Duncan Sands
212a11c417 Fix a nasty bug in LegalizeTypes (spotted in 
CodeGen/PowerPC/illegal-element-type.ll): suppose
a node X is processed, and processing maps it to
a node Y.  Then X continues to exist in the DAG,
but with no users.  While processing some other
node, a new node may be created that happens to
be equal to X, and thus X will be reused rather
than a truly new node.  This can cause X to
"magically reappear", and since it is in the
Processed state in will not be reprocessed, so
at the end of type legalization the illegal node
X can still be present.  The solution is to replace
X with Y whenever X gets resurrected like this.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@47601 91177308-0d34-0410-b5e6-96231b3b80d8
 2008-02-26 11:21:42 +00:00
Duncan Sands
1a9c9df1db In debug builds check that the key property holds: all 
result and operand types are legal.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@47546 91177308-0d34-0410-b5e6-96231b3b80d8
 2008-02-25 16:21:21 +00:00
Duncan Sands
6cb7e6d36b I don't see how NodeUpdated can be called with a 
ReadyToProcess node - add an assertion to check
this.  Add an assertion to NodeDeleted that checks
that processed/ready nodes are indeed not deleted.
It is because they are never deleted that none of
the maps can have a deleted node as the source of
a mapping.  It does however seem to be possible in
theory to have a deleted value as the target of a
mapping, however this has not yet been spotted in
the wild.  Still mulling on what to do about this.
[The theoretical situation is this: a node A is
expanded/promoted/whatever to a newly created node
B.  Thus A->B is added to a map.  When the subtree
rooted at B is legalized it is conceivable that B
is deleted due to RAUW on a node somewhere above
it].


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@46705 91177308-0d34-0410-b5e6-96231b3b80d8
 2008-02-04 09:29:17 +00:00
Chris Lattner
9d3e5d476c Fix typo 
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@46682 91177308-0d34-0410-b5e6-96231b3b80d8
 2008-02-03 07:30:27 +00:00
Chris Lattner
fcd8e9e3a2 handle the case where a node can become ready to process 
multiple times due to a RAUW.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@46680 91177308-0d34-0410-b5e6-96231b3b80d8
 2008-02-03 07:13:32 +00:00
Chris Lattner
42bd25f8ec Use the new infrastructure for listening to node updates to 
keep the LegalizeTypes node flags up to date when doing a RAUW.
This fixes a nasty bug that Duncan ran into and makes the 
previous (nonbuggy case) more efficent.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@46679 91177308-0d34-0410-b5e6-96231b3b80d8
 2008-02-03 07:08:51 +00:00
Chris Lattner
a658baba78 add a -view-legalize-types-dags option, for viewing the dags going into legalize types. 
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@46672 91177308-0d34-0410-b5e6-96231b3b80d8
 2008-02-03 02:05:04 +00:00
Chris Lattner
4ee451de36 Remove attribution from file headers, per discussion on llvmdev. 
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@45418 91177308-0d34-0410-b5e6-96231b3b80d8
 2007-12-29 20:36:04 +00:00
Chris Lattner
e4af7b5a57 implement some methods. 
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44723 91177308-0d34-0410-b5e6-96231b3b80d8
 2007-12-08 22:40:18 +00:00
Chris Lattner
13c6a1740c add scaffolding for splitting of vectors. 
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44722 91177308-0d34-0410-b5e6-96231b3b80d8
 2007-12-08 22:37:41 +00:00
Chris Lattner
ee88813275 split scalarization out to its own file. 
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44718 91177308-0d34-0410-b5e6-96231b3b80d8
 2007-12-08 20:30:28 +00:00
Chris Lattner
cc663a8112 Split expansion out into its own file. 
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44717 91177308-0d34-0410-b5e6-96231b3b80d8
 2007-12-08 20:27:32 +00:00
Chris Lattner
08d1275cb8 Split promotion support out to its own file. 
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44716 91177308-0d34-0410-b5e6-96231b3b80d8
 2007-12-08 20:24:38 +00:00
Chris Lattner
524825b626 Rename LegalizeDAGTypes.cpp -> LegalizeTypes.cpp 
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44715 91177308-0d34-0410-b5e6-96231b3b80d8
 2007-12-08 20:17:13 +00:00