comes after the DW_CFA_def_cfa_register, because the CFA is really ESP from the
start of the function and only gets an offset when the "subl $xxx,%esp"
instruction happens, not the other way around.
And reapply r72898:
The DWARF unwind info was incorrect. While compiling with
`-fomit-frame-pointer', we would lack the DW_CFA_advance_loc information for a
lot of function, and then they would be `0'. The linker (at least on Darwin)
needs to encode the stack size. In some cases, the stack size is too large to
directly encode. So the linker checks to see if there is a "subl $xxx,%esp"
instruction at the point where the `DW_CFA_def_cfa_offset' says the pc was. If
so, the compact encoding records the offset in the function to where the stack
size is embedded. But because the `DW_CFA_advance_loc' instructions are missing,
it looks before the function and dies.
So, instead of emitting the EH debug label before the stack adjustment
operations, emit it afterwards, right before the frame move stuff.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73465 91177308-0d34-0410-b5e6-96231b3b80d8
failures.
To support this, add some utility functions to Type to help support
vector/scalar-independent code. Change ConstantInt::get and
ConstantFP::get to support vector types, and add an overload to
ConstantInt::get that uses a static IntegerType type, for
convenience.
Introduce a new getConstant method for ScalarEvolution, to simplify
common use cases.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73431 91177308-0d34-0410-b5e6-96231b3b80d8
problem addressed in 31284, but the patch there only
addressed the case where an invoke is the first thing in
a block.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73416 91177308-0d34-0410-b5e6-96231b3b80d8
that push immediate operands of 1, 2, and 4 bytes (extended to the native
register size in each case). The assembly mnemonics are "pushl" and "pushq."
One such instruction appears at the beginning of the "start" function , so this
is essential for accurate disassembly when unwinding."
Patch by Sean Callanan!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73407 91177308-0d34-0410-b5e6-96231b3b80d8
specific one. The GNU one is chosen when _GNU_SOURCE is defined. g++ always
defines _GNU_SOURCE on linux platforms because glibc's headers won't compile
in C++ mode without it. The GNU strerror_r doesn't always modify the buffer
which causes empty error messages on linux.
This patch changes MakeErrMsg to use the return value of strerror_r to get
the string instead of assuming the buffer will be modified, on GLIBC.
Patch by Benjamin Kramer!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73396 91177308-0d34-0410-b5e6-96231b3b80d8
incomming chain of the RETURN node. The incomming chain must
be the outgoing chain of the CALL node. This causes the
backend to identify tail calls that are not tail calls. This
patch fixes this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73387 91177308-0d34-0410-b5e6-96231b3b80d8
- Change register allocation hint to a pair of unsigned integers. The hint type is zero (which means prefer the register specified as second part of the pair) or entirely target dependent.
- Allow targets to specify alternative register allocation orders based on allocation hint.
Part 2.
- Use the register allocation hint system to implement more aggressive load / store multiple formation.
- Aggressively form LDRD / STRD. These are formed *before* register allocation. It has to be done this way to shorten live interval of base and offset registers. e.g.
v1025 = LDR v1024, 0
v1026 = LDR v1024, 0
=>
v1025,v1026 = LDRD v1024, 0
If this transformation isn't done before allocation, v1024 will overlap v1025 which means it more difficult to allocate a register pair.
- Even with the register allocation hint, it may not be possible to get the desired allocation. In that case, the post-allocation load / store multiple pass must fix the ldrd / strd instructions. They can either become ldm / stm instructions or back to a pair of ldr / str instructions.
This is work in progress, not yet enabled.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73381 91177308-0d34-0410-b5e6-96231b3b80d8
they contain multiplications of constants with add operations.
This helps simplify several kinds of things; in particular it
helps simplify expressions like ((-1 * (%a + %b)) + %a) to %b,
as expressions like this often come up in loop trip count
computations.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73361 91177308-0d34-0410-b5e6-96231b3b80d8
even though the order doesn't matter at the top level of an expression,
it does matter when the constant is a subexpression of an n-ary
expression, because n-ary expressions are sorted lexicographically.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73358 91177308-0d34-0410-b5e6-96231b3b80d8
is that, for functions whose bodies are entirely guarded by an if-statement, it
can be profitable to pull the test out of the callee and into the caller.
This code has had some cursory testing, but still has a number of known issues
on the LLVM test suite.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73338 91177308-0d34-0410-b5e6-96231b3b80d8
induction variable when the addrec to be expanded does not require
a wider type. This eliminates the need for IndVarSimplify to
micro-manage SCEV expansions, because SCEVExpander now
automatically expands them in the form that IndVarSimplify considers
to be canonical. (LSR still micro-manages its SCEV expansions,
because it's optimizing for the target, rather than for
other optimizations.)
Also, this uses the new getAnyExtendExpr, which has more clever
expression simplification logic than the IndVarSimplify code it
replaces, and this cleans up some ugly expansions in code such as
the included masked-iv.ll testcase.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73294 91177308-0d34-0410-b5e6-96231b3b80d8
consecutive addresses togther. This makes it easier for the post-allocation pass
to form ldm / stm.
This is step 1. We are still missing a lot of ldm / stm opportunities because
of register allocation are not done in the desired order. More enhancements
coming.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73291 91177308-0d34-0410-b5e6-96231b3b80d8
the relationship with MergeFunctions.cpp's isEquivalentOperation,
and make a trivial code reordering so that the two functions are
easier to compare.
Fix the name of Instruction::isSameOperationAs in MergeFunction.cpp's
isEquivalentOperation's comment, and fix a nearby 80-column violation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73241 91177308-0d34-0410-b5e6-96231b3b80d8
out of sync with regular cc.
The only difference between the tail call cc and the normal
cc was that one parameter register - R9 - was reserved for
calling functions through a function pointer. After time the
tail call cc has gotten out of sync with the regular cc.
We can use R11 which is also caller saved but not used as
parameter register for potential function pointers and
remove the special tail call cc on x86-64.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73233 91177308-0d34-0410-b5e6-96231b3b80d8
points to while analyzing all other fields.
Use FoldingSetNodeID to produce a good hash. This dramatically decreases run
times.
Emit thunks. This means that it can look at all functions regardless of what
the linkage is or if the address is taken, but unfortunately some small
functions can be even shorter than the thunk because our backend doesn't yet
realize it can just turn these into jumps. This means that this pass will
pessimize code on average.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73222 91177308-0d34-0410-b5e6-96231b3b80d8
Emission for globals, using the correct data sections
Function alignment can be computed for each target using TargetELFWriterInfo
Some small fixes
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73201 91177308-0d34-0410-b5e6-96231b3b80d8
identical function ConstantIsDead() to SafeToDestroyConstant(), to
emphasise the connection with Constant::destroyConstant().
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73149 91177308-0d34-0410-b5e6-96231b3b80d8
immediately casted. At present, this is just a minor code
simplification. In the future, the expansion code may be able
to make better choices if it knows what the desired result
type will be.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73137 91177308-0d34-0410-b5e6-96231b3b80d8
ABI. The missing piece is support for putting "homogeneous aggregates"
into registers.
Patch by Sandeep Patel!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73095 91177308-0d34-0410-b5e6-96231b3b80d8
Also create isValidElementType for ArrayType, PointerType, StructType and
VectorType.
Make LLParser use them. This closes up some holes like an assertion failure on:
%x = type {label}
but largely doesn't change any semantics. The only thing we accept now which
we didn't before is vectors of opaque type such as "<4 x opaque>". The opaque
can be resolved to an int or float when linking.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73016 91177308-0d34-0410-b5e6-96231b3b80d8
on x86 to handle more cases. Fix a bug in said code that would cause it
to read past the end of an object. Rewrite the code in
SelectionDAGLegalize::ExpandBUILD_VECTOR to be a bit more general.
Remove PerformBuildVectorCombine, which is no longer necessary with
these changes. In addition to simplifying the code, with this change,
we can now catch a few more cases of consecutive loads.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73012 91177308-0d34-0410-b5e6-96231b3b80d8
