to carry a SmallVector of flagged nodes, just calculate the flagged nodes
dynamically when they are needed.
The local-liveness change is due to a trivial scheduling change where
the scheduler arbitrary decision differently.
llvm-svn: 59273
virtual registers possibly having multiple kills while still
being defined and killed in the same block. If LiveIntervals
is manually re-run after two-address lowering, it currently
does add extra kills to two-address instructions, but this
is considered a bug.
llvm-svn: 59194
special-purpose hook to a new pass. Also, add check to see if any
x87 virtual registers are used, to avoid doing any work in the
common case that no x87 code is needed.
llvm-svn: 59190
no longer records a unique defining instruction, and virtual
registers may have multiple kills while still being defined
and killed in the same block.
llvm-svn: 59145
support targets that support these conversions. Users should avoid using
this node as the current targets don't generating code for it.
llvm-svn: 59001
release-asserts build:
llvm/CodeGen/SelectionDAGNodes.h:1298: warning: control may reach end of non-void function 'unsigned int llvm::MVT::getSizeInBits() const' being inlined
what an unhelpful warning.
llvm-svn: 58957
the condition for a BRCOND, according to what is
returned by getSetCCResultContents. Since all
targets return the same thing (ZeroOrOneSetCCResult),
this should be harmless! The point is that all over
the place the result of SETCC is fed directly into
BRCOND. On machines for which getSetCCResultContents
returns ZeroOrNegativeOneSetCCResult, this is a
sign-extended boolean. So it seems dangerous to
also feed BRCOND zero-extended booleans in some
circumstances - for example, when promoting the
condition.
llvm-svn: 58861
- stackprotector_prologue creates a stack object and stores the guard there.
- stackprotector_epilogue reads the stack guard from the stack position created
by stackprotector_prologue.
- The PrologEpilogInserter was changed to make sure that the stack guard is
first on the stack frame.
llvm-svn: 58791
priority function. Instead, just iterate over the AllNodes list, which is
already in topological order. This eliminates a fair amount of bookkeeping,
and speeds up the isel phase by about 15% on many testcases.
The impact on most targets is that AddToISelQueue calls can be simply removed.
In the x86 target, there are two additional notable changes.
The rule-bending AND+SHIFT optimization in MatchAddress that creates new
pre-isel nodes during isel is now a little more verbose, but more robust.
Instead of either creating an invalid DAG or creating an invalid topological
sort, as it has historically done, it can now just insert the new nodes into
the node list at a position where they will be consistent with the topological
ordering.
Also, the address-matching code has logic that checked to see if a node was
"already selected". However, when a node is selected, it has all its uses
taken away via ReplaceAllUsesWith or equivalent, so it won't recieve any
further visits from MatchAddress. This code is now removed.
llvm-svn: 58748
- Use enums instead of magic numbers.
- Rework algorithm to use the bytes size from the target to determine when to
emit stack protectors.
- Get rid of "propolice" in any comments.
- Renamed an option to its expanded form.
- Other miscellanenous changes.
More changes will come after this.
llvm-svn: 58723
* 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
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
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
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
