to use different mappings for EH and debug info;
no functional change yet.
Fix warning in X86CodeEmitter.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@44056 91177308-0d34-0410-b5e6-96231b3b80d8
should only effect x86 when using long double. Now
12/16 bytes are output for long double globals (the
exact amount depends on the alignment). This brings
globals in line with the rest of LLVM: the space
reserved for an object is now always the ABI size.
One tricky point is that only 10 bytes should be
output for long double if it is a field in a packed
struct, which is the reason for the additional
argument to EmitGlobalConstant.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@43688 91177308-0d34-0410-b5e6-96231b3b80d8
or getTypeSizeInBits as appropriate in ScalarReplAggregates.
The right change to make was not always obvious, so it would
be good to have an sroa guru review this. While there I noticed
some bugs, and fixed them: (1) arrays of x86 long double have
holes due to alignment padding, but this wasn't being spotted
by HasStructPadding (renamed to HasPadding). The same goes
for arrays of oddly sized ints. Vectors also suffer from this,
in fact the problem for vectors is much worse because basic
vector assumptions seem to be broken by vectors of type with
alignment padding. I didn't try to fix any of these vector
problems. (2) The code for extracting smaller integers from
larger ones (in the "int union" case) was wrong on big-endian
machines for integers with size not a multiple of 8, like i1.
Probably this is impossible to hit via llvm-gcc, but I fixed
it anyway while there and added a testcase. I also got rid of
some trailing whitespace and changed a function name which
had an obvious typo in it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@43672 91177308-0d34-0410-b5e6-96231b3b80d8
The meaning of getTypeSize was not clear - clarifying it is important
now that we have x86 long double and arbitrary precision integers.
The issue with long double is that it requires 80 bits, and this is
not a multiple of its alignment. This gives a primitive type for
which getTypeSize differed from getABITypeSize. For arbitrary precision
integers it is even worse: there is the minimum number of bits needed to
hold the type (eg: 36 for an i36), the maximum number of bits that will
be overwriten when storing the type (40 bits for i36) and the ABI size
(i.e. the storage size rounded up to a multiple of the alignment; 64 bits
for i36).
This patch removes getTypeSize (not really - it is still there but
deprecated to allow for a gradual transition). Instead there is:
(1) getTypeSizeInBits - a number of bits that suffices to hold all
values of the type. For a primitive type, this is the minimum number
of bits. For an i36 this is 36 bits. For x86 long double it is 80.
This corresponds to gcc's TYPE_PRECISION.
(2) getTypeStoreSizeInBits - the maximum number of bits that is
written when storing the type (or read when reading it). For an
i36 this is 40 bits, for an x86 long double it is 80 bits. This
is the size alias analysis is interested in (getTypeStoreSize
returns the number of bytes). There doesn't seem to be anything
corresponding to this in gcc.
(3) getABITypeSizeInBits - this is getTypeStoreSizeInBits rounded
up to a multiple of the alignment. For an i36 this is 64, for an
x86 long double this is 96 or 128 depending on the OS. This is the
spacing between consecutive elements when you form an array out of
this type (getABITypeSize returns the number of bytes). This is
TYPE_SIZE in gcc.
Since successive elements in a SequentialType (arrays, pointers
and vectors) need to be aligned, the spacing between them will be
given by getABITypeSize. This means that the size of an array
is the length times the getABITypeSize. It also means that GEP
computations need to use getABITypeSize when computing offsets.
Furthermore, if an alloca allocates several elements at once then
these too need to be aligned, so the size of the alloca has to be
the number of elements multiplied by getABITypeSize. Logically
speaking this doesn't have to be the case when allocating just
one element, but it is simpler to also use getABITypeSize in this
case. So alloca's and mallocs should use getABITypeSize. Finally,
since gcc's only notion of size is that given by getABITypeSize, if
you want to output assembler etc the same as gcc then getABITypeSize
is the size you want.
Since a store will overwrite no more than getTypeStoreSize bytes,
and a read will read no more than that many bytes, this is the
notion of size appropriate for alias analysis calculations.
In this patch I have corrected all type size uses except some of
those in ScalarReplAggregates, lib/Codegen, lib/Target (the hard
cases). I will get around to auditing these too at some point,
but I could do with some help.
Finally, I made one change which I think wise but others might
consider pointless and suboptimal: in an unpacked struct the
amount of space allocated for a field is now given by the ABI
size rather than getTypeStoreSize. I did this because every
other place that reserves memory for a type (eg: alloca) now
uses getABITypeSize, and I didn't want to make an exception
for unpacked structs, i.e. I did it to make things more uniform.
This only effects structs containing long doubles and arbitrary
precision integers. If someone wants to pack these types more
tightly they can always use a packed struct.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@43620 91177308-0d34-0410-b5e6-96231b3b80d8
transformation. Previously, it's restricted by ensuring the number of load uses
is one. Now the restriction is loosened up by allowing setcc uses to be
"extended" (e.g. setcc x, c, eq -> setcc sext(x), sext(c), eq).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@43465 91177308-0d34-0410-b5e6-96231b3b80d8
Turn a store folding instruction into a load folding instruction. e.g.
xorl %edi, %eax
movl %eax, -32(%ebp)
movl -36(%ebp), %eax
orl %eax, -32(%ebp)
=>
xorl %edi, %eax
orl -36(%ebp), %eax
mov %eax, -32(%ebp)
This enables the unfolding optimization for a subsequent instruction which will
also eliminate the newly introduced store instruction.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@43192 91177308-0d34-0410-b5e6-96231b3b80d8
types. This is needed for SIGN_EXTEND_INREG at least.
It is not clear if this is correct for other operations.
On the other hand, for the various load/store actions
it seems to correct to return the type action, as is
currently done.
Also, it seems that SelectionDAG::getValueType can be
called for extended value types; introduce a map for
holding these, since we don't really want to extend
the vector to be 2^32 pointers long!
Generalize DAGTypeLegalizer::PromoteResult_TRUNCATE
and DAGTypeLegalizer::PromoteResult_INT_EXTEND to handle
the various funky possibilities that apints introduce,
for example that you can promote to a type that needs
to be expanded.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@43071 91177308-0d34-0410-b5e6-96231b3b80d8
codegen support. This should have no effect on codegen
for other types. Debatable bits: (1) the use (abuse?)
of a set in SDNode::getValueTypeList; (2) the length of
getTypeToTransformTo, which maybe should be refactored
with a non-inline part for extended value types.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@43030 91177308-0d34-0410-b5e6-96231b3b80d8
register used by the unfolded instructions. User can also specify whether to
unfold the load, the store, or both.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@42946 91177308-0d34-0410-b5e6-96231b3b80d8
for fastcc from X86CallingConv.td. This means that nested functions
are not supported for calling convention 'fastcc'.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@42934 91177308-0d34-0410-b5e6-96231b3b80d8
enabled by passing -tailcallopt to llc. The optimization is
performed if the following conditions are satisfied:
* caller/callee are fastcc
* elf/pic is disabled OR
elf/pic enabled + callee is in module + callee has
visibility protected or hidden
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@42870 91177308-0d34-0410-b5e6-96231b3b80d8
address (not just from / to frameindexes).
- Added target hooks to unfold load / store instructions / SDNodes into separate
load, data processing, store instructions / SDNodes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@42621 91177308-0d34-0410-b5e6-96231b3b80d8
other than PPC64. Instead of fixing it, just remove it and fix all the
places that use it to use TargetData::getPointerSize() instead, as there
aren't very many. Most of the references were in DwarfWriter.cpp.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@42419 91177308-0d34-0410-b5e6-96231b3b80d8
keep f32 in SSE registers and f64 in x87. This
is effectively a new codegen mode.
Change addLegalFPImmediate to permit float and
double variants to do different things.
Adjust callers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@42246 91177308-0d34-0410-b5e6-96231b3b80d8
Add APFloat interfaces to ConstantFP, SelectionDAG.
Fix integer bit in double->APFloat conversion.
Convert LegalizeDAG to use APFloat interface in
ConstantFPSDNode uses.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@41587 91177308-0d34-0410-b5e6-96231b3b80d8
better, gives the compiler a chance to validate the cast and reduces warnings
if the user turns on -Wold-style-cast option.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@41033 91177308-0d34-0410-b5e6-96231b3b80d8
(constants are still not handled). Adds ConvertActions
to control fp-to-fp conversions (these are currently
defaulted for all other targets, so no changes there).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@40958 91177308-0d34-0410-b5e6-96231b3b80d8
This patch fills the last necessary bits to enable exceptions
handling in LLVM. Currently only on x86-32/linux.
In fact, this patch adds necessary intrinsics (and their lowering) which
represent really weird target-specific gcc builtins used inside unwinder.
After corresponding llvm-gcc patch will land (easy) exceptions should be
more or less workable. However, exceptions handling support should not be
thought as 'finished': I expect many small and not so small glitches
everywhere.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@39855 91177308-0d34-0410-b5e6-96231b3b80d8
illegal value type will be transformed to, for code that needs the
register type after all transformations instead of just after the first
transformation.
Factor out the code that uses this information to do copy-from-regs and
copy-to-regs for various purposes into separate functions so that they
are done consistently.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@37781 91177308-0d34-0410-b5e6-96231b3b80d8
instruction flag, and use the flag along with a virtual member function
hook for targets to override if there are instructions that are only
trivially rematerializable with specific operands (i.e. constant pool
loads).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@37728 91177308-0d34-0410-b5e6-96231b3b80d8
extended vector types. Remove the special SDNode opcodes used for pre-legalize
vector operations, and the special MVT::Vector type used with them. Adjust
lowering and legalize to work with the normal SDNode kinds instead, and to
use the normal MVT functions to work with vector types instead of using the
two special operands that the pre-legalize nodes held.
This allows pre-legalize and post-legalize DAGs, and the code that operates
on them, to be more consistent. Pre-legalize vector operators can be handled
more consistently with scalar operators. And, -view-dag-combine1-dags and
-view-legalize-dags now look prettier for vector code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@37719 91177308-0d34-0410-b5e6-96231b3b80d8
TargetLowering to SelectionDAG so that they have more convenient
access to the current DAG, in preparation for the ValueType routines
being changed from standalone functions to members of SelectionDAG for
the pre-legalize vector type changes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@37704 91177308-0d34-0410-b5e6-96231b3b80d8
TargetLowering::getNumRegisters and similar, to avoid confusion with
the actual number of elements for vector types.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@37687 91177308-0d34-0410-b5e6-96231b3b80d8
with a general target hook to identify rematerializable instructions. Some
instructions are only rematerializable with specific operands, such as loads
from constant pools, while others are always rematerializable. This hook
allows both to be identified as being rematerializable with the same
mechanism.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@37644 91177308-0d34-0410-b5e6-96231b3b80d8
feature is set, then the features in the implied list should be set also.
The opposite is also enforced: if a feature in the implied list isn't set,
then the feature that owns that implies list shouldn't be set either.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@36756 91177308-0d34-0410-b5e6-96231b3b80d8
Due to darwin gcc bug, one version of darwin linker coalesces
static const int, which defauts PassID based pass identification.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@36652 91177308-0d34-0410-b5e6-96231b3b80d8
1. Correct output offsets on Linux
2. Fix "style" of personality function. It shouldn't be indirect.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@36633 91177308-0d34-0410-b5e6-96231b3b80d8
It means the instruction can be easily re-materialized at any point. e.g.
constant generation, load from constantpool.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@35158 91177308-0d34-0410-b5e6-96231b3b80d8
rules alignment is to pick the alignment that corresponds to the smallest
specified alignment that is larger than the bit width of the type or the
largest specified integer alignment if none are larger than the bitwidth
of the type. For the byte size, the size returned is the next larger
multiple of the alignment for that type (using the above rule). This patch
also changes bit widths from "short" to "uint32_t" to ensure there are
enough bits to specify any bit width that LLVM can handle (currently 2^23);
16-bits isn't enough.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@34431 91177308-0d34-0410-b5e6-96231b3b80d8
Revert patches that caused the problem. Evan, please investigate and reapply
when you've discovered the problem.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@34399 91177308-0d34-0410-b5e6-96231b3b80d8
virtual registers, test if they the same.
- Added a virtual method to return target specific reserved registers, e.g. SP.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@34375 91177308-0d34-0410-b5e6-96231b3b80d8
after the StructLayout object in memory. This marginally improves locality,
speeding up -load-vn -gcse by ~0.8%.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@34158 91177308-0d34-0410-b5e6-96231b3b80d8
allows us to split that method into two so that we can optionally call a
concrete function to add a writer. Removed moribund addObjectWriter()
method.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@34030 91177308-0d34-0410-b5e6-96231b3b80d8
1. New parameter attribute called 'inreg'. It has meaning "place this
parameter in registers, if possible". This is some generalization of
gcc's regparm(n) attribute. It's currently used only in X86-32 backend.
2. Completely rewritten CC handling/lowering code inside X86 backend.
Merged stdcall + c CCs and fastcall + fast CC.
3. Dropped CSRET CC. We cannot add struct return variant for each
target-specific CC (e.g. stdcall + csretcc and so on).
4. Instead of CSRET CC introduced 'sret' parameter attribute. Setting in
on first attribute has meaning 'This is hidden pointer to structure
return. Handle it gently'.
5. Fixed small bug in llvm-extract + add new feature to
FunctionExtraction pass, which relinks all internal-linkaged callees
from deleted function to external linkage. This will allow further
linking everything together.
NOTEs: 1. Documentation will be updated soon.
2. llvm-upgrade should be improved to translate csret => sret.
Before this, there will be some unexpected test fails.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33597 91177308-0d34-0410-b5e6-96231b3b80d8
non-statics.
* Introduce new option to output zero-initialized data to .bss section.
This can reduce size of binaries. Enable it by default for ELF &
Cygwin/Mingw targets. Probably, Darwin should be also added.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33299 91177308-0d34-0410-b5e6-96231b3b80d8
