| Age | Commit message (Collapse) | Author |
|---|
|
a win.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52452 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52450 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52431 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
that are not affected.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52430 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
movl %eax, %eax on x86-64 actually does a zero-extend.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52421 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
rather than bundling them together. Rename FloatToInt
to PromoteFloat (better, if not perfect). Reorganize
files by types rather than by operations.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52408 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
of value info (sign/zero ext info) from one MBB to another. This doesn't
handle much right now because of two limitations:
1) only handles zext/sext, not random bit propagation (no assert exists
for this)
2) doesn't handle phis.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52383 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52381 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52373 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52345 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
impact on code quality or compile time.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52329 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
still excluding types like i1 (not byte sized)
and i120 (loading an i120 requires loading an i64,
an i32, an i16 and an i8, which is expensive).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52310 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52309 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
(commuted) instruction.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52308 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52306 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
StrongPHIElimination in the near future.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52300 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
not valid if the load is volatile. Hopefully
all wrong DAG combiner transforms of volatile
loads and stores have now been caught.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52293 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
a non-constant index.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52292 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
on some code when !AfterLegalize - but since
this whole code section is turned off by an
"if (0)" it's not really turning anything on.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52276 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52270 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
hits 410 times on 444.namd and 122 times on 252.eon.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52266 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
wrong for volatile loads and stores. In fact this
is almost all of them! There are three types of
problems: (1) it is wrong to change the width of
a volatile memory access. These may be used to
do memory mapped i/o, in which case a load can have
an effect even if the result is not used. Consider
loading an i32 but only using the lower 8 bits. It
is wrong to change this into a load of an i8, because
you are no longer tickling the other three bytes. It
is also unwise to make a load/store wider. For
example, changing an i16 load into an i32 load is
wrong no matter how aligned things are, since the
fact of loading an additional 2 bytes can have
i/o side-effects. (2) it is wrong to change the
number of volatile load/stores: they may be counted
by the hardware. (3) it is wrong to change a volatile
load/store that requires one memory access into one
that requires several. For example on x86-32, you
can store a double in one processor operation, but to
store an i64 requires two (two i32 stores). In a
multi-threaded program you may want to bitcast an i64
to a double and store as a double because that will
occur atomically, and be indivisible to other threads.
So it would be wrong to convert the store-of-double
into a store of an i64, because this will become two
i32 stores - no longer atomic. My policy here is
to say that the number of processor operations for
an illegal operation is undefined. So it is alright
to change a store of an i64 (requires at least two
stores; but could be validly lowered to memcpy for
example) into a store of double (one processor op).
In short, if the new store is legal and has the same
size then I say that the transform is ok. It would
also be possible to say that transforms are always
ok if before they were illegal, whether after they
are illegal or not, but that's more awkward to do
and I doubt it buys us anything much.
However this exposed an interesting thing - on x86-32
a store of i64 is considered legal! That is because
operations are marked legal by default, regardless of
whether the type is legal or not. In some ways this
is clever: before type legalization this means that
operations on illegal types are considered legal;
after type legalization there are no illegal types
so now operations are only legal if they really are.
But I consider this to be too cunning for mere mortals.
Better to do things explicitly by testing AfterLegalize.
So I have changed things so that operations with illegal
types are considered illegal - indeed they can never
map to a machine operation. However this means that
the DAG combiner is more conservative because before
it was "accidentally" performing transforms where the
type was illegal because the operation was nonetheless
marked legal. So in a few such places I added a check
on AfterLegalize, which I suppose was actually just
forgotten before. This causes the DAG combiner to do
slightly more than it used to, which resulted in the X86
backend blowing up because it got a slightly surprising
node it wasn't expecting, so I tweaked it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52254 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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
|
|
value, which is something that apparently isn't used much.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52158 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52156 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
change for non-funky-sized integers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52151 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52150 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
of integer types. Fix the isMask APInt method to
actually work (hopefully) rather than crashing
because it adds apints of different bitwidths.
It looks like isShiftedMask is also broken, but
I'm leaving that one to the APInt people (it is
not used anywhere).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52142 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
of apint codegen failure is the DAG combiner doing
the wrong thing because it was comparing MVT's using
< rather than comparing the number of bits. Removing
the < method makes this mistake impossible to commit.
Instead, add helper methods for comparing bits and use
them.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52098 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
stores of aggregate values.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52069 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
no visible functionality change, but enables a future patch where node creation
will update the CFG if it decides to create an unconditional rather than a conditional branch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52067 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52057 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52045 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52040 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52016 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52013 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
to the end of its MBB.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@52012 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
the desired alignment, the frame destination alignment may still be larger than the desired alignment. Don't change its alignment to something smaller.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51970 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51953 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
predecessors of a block containing a PHI.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51950 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51949 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51934 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51933 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51932 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51931 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
are the same as in unpacked structs, only field
positions differ. This only matters for structs
containing x86 long double or an apint; it may
cause backwards compatibility problems if someone
has bitcode containing a packed struct with a
field of one of those types.
The issue is that only 10 bytes are needed to
hold an x86 long double: the store size is 10
bytes, but the ABI size is 12 or 16 bytes (linux/
darwin) which comes from rounding the store size
up by the alignment. Because it seemed silly not
to pack an x86 long double into 10 bytes in a
packed struct, this is what was done. I now
think this was a mistake. Reserving the ABI size
for an x86 long double field even in a packed
struct makes things more uniform: the ABI size is
now always used when reserving space for a type.
This means that developers are less likely to
make mistakes. It also makes life easier for the
CBE which otherwise could not represent all LLVM
packed structs (PR2402).
Front-end people might need to adjust the way
they create LLVM structs - see following change
to llvm-gcc.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51928 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51922 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51917 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51904 91177308-0d34-0410-b5e6-96231b3b80d8
|
