| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
when simplify a vector.
llvm-svn: 58820
|
| |
|
|
|
|
| |
in it, then emit stack protectors.
llvm-svn: 58819
|
| |
|
|
| |
llvm-svn: 58815
|
| |
|
|
| |
llvm-svn: 58814
|
| |
|
|
| |
llvm-svn: 58801
|
| |
|
|
|
|
|
| |
- Get rid of "HasStackProtector" in MachineFrameInfo.
- Modify intrinsics to tell which are doing what with memory.
llvm-svn: 58799
|
| |
|
|
| |
llvm-svn: 58796
|
| |
|
|
|
|
| |
"alloca".
llvm-svn: 58792
|
| |
|
|
|
|
|
|
|
|
|
|
| |
- 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
|
| |
|
|
| |
llvm-svn: 58786
|
| |
|
|
| |
llvm-svn: 58753
|
| |
|
|
| |
llvm-svn: 58751
|
| |
|
|
| |
llvm-svn: 58741
|
| |
|
|
| |
llvm-svn: 58740
|
| |
|
|
| |
llvm-svn: 58739
|
| |
|
|
|
|
| |
bug.
llvm-svn: 58738
|
| |
|
|
|
|
| |
isn't going to be generated.
llvm-svn: 58734
|
| |
|
|
| |
llvm-svn: 58728
|
| |
|
|
|
|
|
|
|
|
| |
"getOrInsertFunction" in that it either adds a new declaration of the global
and returns it, or returns the current one -- optionally casting it to the
correct type.
- Use the new getOrInsertGlobal in the stack protector code.
- Use "splitBasicBlock" in the stack protector code.
llvm-svn: 58727
|
| |
|
|
|
|
| |
pre-alloc splitting. This is not turned on yet.
llvm-svn: 58726
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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
|
| |
|
|
| |
llvm-svn: 58717
|
| |
|
|
| |
llvm-svn: 58709
|
| |
|
|
|
|
| |
SELECT_CC.
llvm-svn: 58706
|
| |
|
|
| |
llvm-svn: 58690
|
| |
|
|
| |
llvm-svn: 58676
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* 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
|
| |
|
|
|
|
|
| |
work correctly, and bring over a late change to ppcf128
SetCC handling.
llvm-svn: 58642
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
10 bytes long, but is passed in 12/16 bytes).
llvm-svn: 58608
|
| |
|
|
| |
llvm-svn: 58606
|
| |
|
|
| |
llvm-svn: 58591
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
target intrinsics that touches memory
llvm-svn: 58548
|
| |
|
|
|
|
| |
Based on patch by Martin Nowack!
llvm-svn: 58536
|
| |
|
|
| |
llvm-svn: 58524
|
| |
|
|
| |
llvm-svn: 58523
|
| |
|
|
| |
llvm-svn: 58514
|
| |
|
|
|
|
| |
completely forgotten about when writing LegalizeTypes.
llvm-svn: 58508
|
| |
|
|
|
|
|
| |
callee-saved restore code. It could skip over conditional jumps
accidentally. Instead, just skip the "return" instructions.
llvm-svn: 58489
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 58443
|
| |
|
|
|
|
|
| |
One will only see an effect if legalizetype is not active. Will move
support to LegalizeType soon.
llvm-svn: 58426
|
| |
|
|
| |
llvm-svn: 58386
|
| |
|
|
|
|
| |
VAARG.
llvm-svn: 58379
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
point bug.
- If a def is spilt, remember its spill index to allow its reuse.
llvm-svn: 58375
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 58371
|
| |
|
|
| |
llvm-svn: 58370
|