[PATCH] D17736: [SSP, 1/2] Refactor to support customizable stack guard load from IR level.

Eric Christopher via llvm-commits llvm-commits at lists.llvm.org
Mon Mar 21 16:39:38 PDT 2016


echristo added a comment.

Overall I think we're going to want a path that takes us through AutoUpgrade so that going forward we have a single path for all targets.

<insert about 30-45 minutes of discussion>

We're looking at a major design overhaul here, I think, so getting some notes down:

TLI->

  lowerStackGuardStore
  lowerStackGuardLoad
  lowerStackCanaryLoad

We already have a guard node, do we need a separate SDag node for each of these?

Do we need this, effectively, duplicated 3x with SDag, FastIsel, Post-RA handling?

How do we keep the analysis information in the analysis pass and the rest of it in the IR? This would be the other side information like how to sort, strong, etc.

Need to continue to handle:

  Coloring reuse
  Sibcall optimizations
  Avoid stack spill of canary values
  Architecture neutral base case

and of course all of this with auto upgrade because I like my ponies to have unicorn horns.


http://reviews.llvm.org/D17736





More information about the llvm-commits mailing list