* The prologue is modified to read the __stack_chk_guard global and insert it
onto the stack.
* The epilogue is modified to read the stored guard from the stack and compare
it to the original __stack_chk_guard value. If they differ, then the
__stack_chk_fail() function is called.
* The stack protector needs to be first on the stack (after the parameters) to
catch any stack-smashing activities.
Front-end support will follow after a round of beta testing.
llvm-svn: 58673
sized integers like i129, and also reduce the number
of assumptions made about how vaarg is implemented.
This still doesn't work correctly for small integers
like (eg) i1 on x86, since x86 passes each of them
(essentially an i8) in a 4 byte stack slot, so the
pointer needs to be advanced by 4 bytes not by 1 byte
as now. But this is no longer a LegalizeTypes problem
(it was also wrong in LT before): it is a bug in the
operation expansion in LegalizeDAG: now LegalizeTypes
turns an i1 vaarg into an i8 vaarg which would work
fine if only the i8 vaarg was turned into correct code
later.
llvm-svn: 58635
This allows SCEV users to effectively calculate trip count.
LSR later on transforms back integer IVs to floating point IVs
later on to avoid int-to-float casts inside the loop.
llvm-svn: 58625
bits, use a union of a SimpleValueType enum and a regular Type*.
This increases the size of MVT on 64-bit hosts from 32 bits to 64 bits.
In most cases, this doesn't add significant overhead. There are places
in codegen that use arrays of MVTs, so these are now larger, but
they're small in common cases.
This eliminates restrictions on the size of integer types and vector
types that can be represented in codegen. As the included testcase
demonstrates, it's now possible to codegen very large add operations.
There are still some complications with using very large types. PR2880
is still open so they can't be used as return values on normal targets,
there are no libcalls defined for very large integers so operations
like multiply and divide aren't supported.
This also introduces a minimal tablgen Type library, capable of
handling IntegerType and VectorType. This will allow parts of
TableGen that don't depend on using SimpleValueType values to handle
arbitrary integer and vector types.
llvm-svn: 58623
* merge two weak functions by making them both alias a third non-weak fn
* don't reimplement CallSite::hasArgument
* whitelist the safe linkage types
llvm-svn: 58568
exist before. Updating the live intervals in that care is tricky in the general
case.
Evan, if you see a tighter guard condition for this, let me know.
llvm-svn: 58560
This triggers only 60 times in llvm-test (look at .llvm.bc, not .linked.rbc)
and so it probably wont be turned on by default. Also, may of those are likely
to go away when PR2973 is fixed.
llvm-svn: 58557
type for the shift amount type. Add a check
that shifts and rotates use the type returned
by getShiftAmountTy for the amount. This
exposed some problems in CellSPU and PPC,
which have already been fixed.
llvm-svn: 58455
function.
- This explicitly models the costs for functions which should
"always" or "never" be inlined. This fixes bugs where such costs
were not previously respected.
llvm-svn: 58450
so that va_start/va_arg/et.al. will walk arguments correctly for Cell SPU.
N.B.: Because neither clang nor llvm-gcc-4.2 can be built for CellSPU, this is
still unexorcised code.
llvm-svn: 58415
allows ppcf128->int conversion to work with
DeadInstructionElimination. This is now turned
off but RM is harmless. It does not do a complete
job of modeling the rounding mode.
Revert marking MFCR as using all 7 CR subregisters;
while correct, this caused the problem in PR 2964,
plus the local RA crash noted in the comments.
This was needed to make DeadInstructionElimination,
but as we are not running that, it is backed out
for now. Eventually it should go back in and the
other problems fixed where they're broken.
llvm-svn: 58391
other day that PPC custom lowering could create
a BUILD_PAIR of two f64 with a result type of...
f64! - already fixed). Fix a place that triggers
the sanity check.
llvm-svn: 58378
is morphed by AnalyzeNewNode into a previously
processed node, and different result values of
that node are remapped to values with different
nodes, then we could end up using wrong values
here [we were assuming that all results remap
to values with the same underlying node]. This
seems theoretically possible, but I don't have
a testcase. The meat of the patch is in the
changes to AnalyzeNewNode/AnalyzeNewValue and
ReplaceNodeWith. While there, I changed names
like RemapNode to RemapValue, since it really
remaps values. To tell the truth, I would be
much happier if we were only remapping nodes
(it would simplify a bunch of logic, and allow
for some cute speedups) but I haven't yet worked
out how to do that.
llvm-svn: 58372
- One functionality change, '\\' in a name is now printed as a hex
escape instead of "\\\\". This is consistent with other users of
PrintEscapedString.
llvm-svn: 58343
Since the ARM constant pool handling supercedes the standard LLVM constant
pool entirely, the JIT emitter does not allocate space for the constants,
nor initialize the memory. The constant pool is considered part of the
instruction stream.
Likewise, when resolving relocations into the constant pool, a hook into
the target back end is used to resolve from the constant ID# to the
address where the constant is stored.
For now, the support in the ARM emitter is limited to 32-bit integer. Future
patches will expand this to the full range of constants necessary.
llvm-svn: 58338
ppcf128 to i32 conversion and expand it into a code
sequence like in LegalizeDAG. This needs custom
ppc lowering of FP_ROUND_INREG, so turn that on and
make it work with LegalizeTypes. Probably PPC should
simply custom lower the original conversion.
llvm-svn: 58329
a memset using 16-byte XMM stores, but where the stack realignment code
didn't work. Until it does (PR2962) disable use of xmm regs in memcpy
and memset formation for linux and other targets with insufficiently
aligned stacks.
This is part of PR2888
llvm-svn: 58317
- Add VERBOSE=1 flag.
- Specify the LLVM_SUBMIT_VERSION when doing the "make install".
The libLTO.dylib relies upon this flag during that time.
llvm-svn: 58298
flag. Then in a debugger developers can set breakpoints at these calls
to see waht is about to be selected and what the resulting subgraph
looks like. This really helps when debugging instruction selection.
llvm-svn: 58278
can give it the same stack slot as the spilled interval if it is folded.
This prevents the fold/unfold code from pointing to the wrong register.
llvm-svn: 58255
(and a bunch of other node types). While there, I
added a doNotCSE predicate and used it to reduce code
duplication (some of the duplicated code was wrong...).
This fixes ARM/cse-libcalls.ll when using LegalizeTypes.
llvm-svn: 58249
worklist twice: UpdateNodeOperands could morph
a new node into a node already on the worklist.
We would then recalculate the NodeId for this
existing node and add it to the worklist. The
testcase is ARM/cse-libcalls.ll, the problem
showing up once UpdateNodeOperands is taught to
do CSE for calls.
llvm-svn: 58246
LargeBlockInfo, we can now dramatically simplify their implementation
and speed them up at the same time. Now the code has time proportional
to the number of uses of the alloca, not the size of the block.
This also eliminates code that tried to batch up different allocas which
are used in the same blocks, and eliminates the 'retry list' logic which
was baroque and no unneccesary. In addition to being a speedup for crazy
cases, this is also a nice cleanup:
PromoteMemoryToRegister.cpp | 270 +++++++++++++++-----------------------------
1 file changed, 96 insertions(+), 174 deletions(-)
llvm-svn: 58229
a trivial dense map. Use this in RewriteSingleStoreAlloca to
avoid aggressively rescanning blocks over and over again. This
fixes PR2925, speeding up mem2reg on the testcase in that bug
from 4.56s to 0.02s in a debug build on my machine.
llvm-svn: 58227
target-independent code to target-specific code. This prevents it
from running on targets that aren't using fast-isel.
In addition to saving compile time, this addresses the problem
that not all targets are prepared for it. In order to use this
pass, all instructions must declare all their fixed uses and
defs of physical registers.
llvm-svn: 58144
variable is moved to the execution engine. The JIT calls the TargetJITInfo
to allocate thread local storage. Currently, only linux/x86 knows how to
allocate thread local global variables.
llvm-svn: 58142
LHS is a foldable load, then LHS and RHS are swapped
and SetCCOpcode is changed to SETUGT. But the later
code is expecting operands to be the wrong way round
for SETUGT, but they are not in this case, resulting
in an inverted compare. The solution is to move the
load normalization before the correction for SETUGT.
This bug was tickled by LegalizeTypes which happened
to legalize the testcase slightly differently to
LegalizeDAG.
llvm-svn: 58092
- Add a file to the VC++ project.
- Make sure the clang driver links against the Transforms library.
- Incorporate changes from patch by Dan Gohman.
llvm-svn: 58048
LoopPass*.
- Although less precise, this means they can be used in clients
without RTTI (who would otherwise need to include LoopPass.h, which
eventually includes things using dynamic_cast). This was the
simplest solution that presented itself, but I am happy to use a
better one if available.
llvm-svn: 58010
assume that i64 has been turned into a BUILD_PAIR
node (when called from LegalizeTypes this hasn't
happened yet) and don't use a vector shuffle mask
with an illegal element type.
llvm-svn: 57972
may return i8, which can result in SELECT nodes for
which the type of the condition is i8, but there are
no patterns for select with i8 condition. Tweak the
LegalizeTypes logic to avoid this as much as possible.
This isn't a real fix because it is still perfectly
possible to end up with such select nodes - CellSPU
needs to be fixed IMHO.
llvm-svn: 57968
that is not of type MVT::i1 in SELECT and SETCC nodes.
Relax the LegalizeTypes SELECT condition promotion
sanity checks to allow other condition types than i1.
llvm-svn: 57966
to have a different type to the vector element
type. This should be fairly harmless because in
the past guys like this were being built all over
the place (and were cleaned up when I added this
check). The reason for relaxing this check is
that it helps LegalizeTypes legalize vector
shuffles: the mask is a BUILD_VECTOR that it is
*not always possible* to legalize while keeping it
a BUILD_VECTOR (vector_shuffle requires the mask
to be a BUILD_VECTOR, as opposed to a vector with
the right vector type). With this check it is even
harder to legalize the mask - turning the check off
means that LegalizeTypes manages to legalize almost
all vector shuffles encountered in practice. The
correct solution is to change vector_shuffle to be a
variadic node with the mask built into it as operands.
While waiting for that change, this hack stops the
problem with vector_shuffle from blocking the turning
on of LegalizeTypes.
llvm-svn: 57965
The same one Apple gcc uses, faster. Also gets the
extreme case in gcc.c-torture/execute/ieee/rbug.c
correct which we weren't before; this is not
sufficient to get the test to pass though, there
is another bug.
llvm-svn: 57926
in the 32-bit signed offset field of addresses. Even though this
may be intended, some linkers refuse to relocate code where the
relocated address computation overflows.
Also, fix the sign-extension of constant offsets to use the
actual pointer size, rather than the size of the GlobalAddress
node, which may be different, for example on x86-64 where MVT::i32
is used when the address is being fit into the 32-bit displacement
field.
llvm-svn: 57885
Where previously LLVM might emit code like this:
ucomisd %xmm1, %xmm0
setne %al
setp %cl
orb %al, %cl
jne .LBB4_2
it now emits this:
ucomisd %xmm1, %xmm0
jne .LBB4_2
jp .LBB4_2
It has fewer instructions and uses fewer registers, but it does
have more branches. And in the case that this code is followed by
a non-fallthrough edge, it may be followed by a jmp instruction,
resulting in three branch instructions in sequence. Some effort
is made to avoid this situation.
To achieve this, X86ISelLowering.cpp now recognizes FCMP_OEQ and
FCMP_UNE in lowered form, and replace them with code that emits
two branches, except in the case where it would require converting
a fall-through edge to an explicit branch.
Also, X86InstrInfo.cpp's branch analysis and transform code now
knows now to handle blocks with multiple conditional branches. It
uses loops instead of having fixed checks for up to two
instructions. It can now analyze and transform code generated
from FCMP_OEQ and FCMP_UNE.
llvm-svn: 57873
the copy instruction from the instruction list before asking the
target to create the new instruction. This gets the old instruction
out of the way so that it doesn't interfere with the target's
rematerialization code. In the case of x86, this helps it find
more cases where EFLAGS is not live.
Also, in the X86InstrInfo.cpp, teach isSafeToClobberEFLAGS to check
to see if it reached the end of the block after scanning each
instruction, instead of just before. This lets it notice when the
end of the block is only two instructions away, without doing any
additional scanning.
These changes allow rematerialization to clobber EFLAGS in more
cases, for example using xor instead of mov to set the return value
to zero in the included testcase.
llvm-svn: 57872
for strange asm conditions earlier. In this case, we have a
double being passed in an integer reg class. Convert to like
sized integer register so that we allocate the right number
for the class (two i32's for the f64 in this case).
llvm-svn: 57862
is re-written by the callback to branch directly to the compiled code
in future invocations.
Added back in range-based memory permission functions for the updating of
the stub on Darwin.
llvm-svn: 57846
result type when the result type is legal but
not the operand type. Add additional support
for EXTRACT_SUBVECTOR and CONCAT_VECTORS,
needed to handle such cases.
llvm-svn: 57840
sensible for vectors being scalarized. Note
that this method can't return anything very
sensible when splitting non-power-of-two vectors.
llvm-svn: 57839
LowerOperation if it doesn't know what else to do.
This methods should probably be factorized some,
but this is good enough for the moment. Have
LowerATOMIC_BINARY_64 use EXTRACT_ELEMENT rather
than assuming the operand is a BUILD_PAIR (if it
is then getNode will automagically simplify the
EXTRACT_ELEMENT). This way LowerATOMIC_BINARY_64
usable from LegalizeTypes.
llvm-svn: 57831
elements. Otherwise LegalizeTypes will, reasonably
enough, legalize the mask, which may result in it
no longer being a BUILD_VECTOR node (LegalizeDAG
simply ignores the legality or not of vector masks).
llvm-svn: 57782
the previous patch this one actually passes make check.
"Fix PR2356 on PowerPC: if we have an input and output that are tied together
that have different sizes (e.g. i32 and i64) make sure to reserve registers for
the bigger operand."
llvm-svn: 57771
and add a TargetLowering hook for it to use to determine when this
is legal (i.e. not in PIC mode, etc.)
This allows instruction selection to emit folded constant offsets
in more cases, such as the included testcase, eliminating the need
for explicit arithmetic instructions.
This eliminates the need for the C++ code in X86ISelDAGToDAG.cpp
that attempted to achieve the same effect, but wasn't as effective.
Also, fix handling of offsets in GlobalAddressSDNodes in several
places, including changing GlobalAddressSDNode's offset from
int to int64_t.
The Mips, Alpha, Sparc, and CellSPU targets appear to be
unaware of GlobalAddress offsets currently, so set the hook to
false on those targets.
llvm-svn: 57748
have an unreachable block in a function. This was triggering the assert. This is
a horrid hack to cover this up.
Oh! for a good debug info architecture!
llvm-svn: 57714
in 32-bit mode instead of assigning a register pair. This has nothing to
do with PR2356, but I happened to notice it while working on it.
llvm-svn: 57704
distinguished from normal (untagged) ones
as per review comment.
I am sufficiently unaquainted with doxygen to
defer the markup to someone with more experience.
llvm-svn: 57676
use a SUB instruction instead of an ADD, because -128 can be
encoded in an 8-bit signed immediate field, while +128 can't be.
This avoids the need for a 32-bit immediate field in this case.
A similar optimization applies to 64-bit adds with 0x80000000,
with the 32-bit signed immediate field.
To support this, teach tablegen how to handle 64-bit constants.
llvm-svn: 57663
shift counts, and patterns that match dynamic shift counts
when the subtract is obscured by a truncate node.
Add DAGCombiner support for recognizing rotate patterns
when the shift counts are defined by truncate nodes.
Fix and simplify the code for commuting shld and shrd
instructions to work even when the given instruction doesn't
have a parent, and when the caller needs a new instruction.
These changes allow LLVM to use the shld, shrd, rol, and ror
instructions on x86 to replace equivalent code using two
shifts and an or in many more cases.
llvm-svn: 57662
using the 'volatile' qualifier. This should not have any operational consequences
on code, because tags should always be stripped off (giving a non-volatile pointer)
before dereferencing. The new qualification is there to catch some attempts to use
tagged pointers in a context where an untagged pointer is appropriate.
Notably this approach does not catch dereferencing of tagged pointers, but helps
in separating the two concepts a bit.
llvm-svn: 57641
Dale Johannesen