[PATCH] D17736: [SSP, 1/2] Refactor to support customizable stack guard load from IR level.
Tim Shen via llvm-commits
llvm-commits at lists.llvm.org
Wed Mar 23 21:58:58 PDT 2016
timshen updated this revision to Diff 51512.
timshen added a comment.
I looked at LLVM manual and fortunately both llvm.stackprotector and
llvm.stackprotectorcheck is required to be passed in @__stack_chk_guard.
This limited flexibility allows us to directly change stackprotectorcheck's
signature and make an auto-upgrade for it.
In long term, I'd like to keep a diamond code path:
1. An IR pass that generates IR that calls llvm.stackprotector, llvm.stackprotectorcheck and llvm.experimental_stackguardvalue.
2. Either FastISel, or SelectionDAG handles the generated IR. Their shouldn't be an "IR approach" when FastISel isn't turned on (see the comment on TLI::supportsSelectionDAGSP).
3. Optional backend lowering is supported by overriding TLI::forceLoadStackGuardNode and TLI::getStackGuardAddr.
Notice that forceLoadStackGuardNode and getStackGuardAddr serves following
- Some backends want to lower the global variable manually, in such case forceLoadStackGuardNode should return true and getStackGuardAddr returns the global variable (search LOAD_STACK_GUARD in lib/Target).
- Other platforms, e.g. PowerPC 64 bit wants to lower the stack guard loading completely manually, getStackGuardAddr should returns nullptr.
- For the rest forceLoadStackGuardNode returns false and getStackGuardAddr returns the global variable.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 23755 bytes
Desc: not available
More information about the llvm-commits