LLVM: llvm::StackProtectorDescriptor Class Reference (original) (raw)

Encapsulates all of the information needed to generate a stack protector check, and signals to isel when initialized that one needs to be generated. More...

Encapsulates all of the information needed to generate a stack protector check, and signals to isel when initialized that one needs to be generated.

NOTE The following is a high level documentation of SelectionDAG Stack Protector Generation. This is now also ported be shared with GlobalISel, but without any significant changes.

High Level Overview of ISel Stack Protector Generation:

Previously, the "stack protector" IR pass handled stack protector generation. This necessitated splitting basic blocks at the IR level to create the success/failure basic blocks in the tail of the basic block in question. As a result of this, calls that would have qualified for the sibling call optimization were no longer eligible for optimization since said calls were no longer right in the "tail position" (i.e. the immediate predecessor of a ReturnInst instruction).

Since the sibling call optimization causes the callee to reuse the caller's stack, if we could delay the generation of the stack protector check until later in CodeGen after the sibling call decision was made, we get both the tail call optimization and the stack protector check!

A few goals in solving this problem were:

  1. Preserve the architecture independence of stack protector generation.
  2. Preserve the normal IR level stack protector check for platforms like OpenBSD for which we support platform-specific stack protector generation.

The main problem that guided the present solution is that one can not solve this problem in an architecture independent manner at the IR level only. This is because:

  1. The decision on whether or not to perform a sibling call on certain platforms (for instance i386) requires lower level information related to available registers that can not be known at the IR level.
  2. Even if the previous point were not true, the decision on whether to perform a tail call is done in LowerCallTo in SelectionDAG (or CallLowering in GlobalISel) which occurs after the Stack Protector Pass. As a result, one would need to put the relevant callinst into the stack protector check success basic block (where the return inst is placed) and then move it back later at ISel/MI time before the stack protector check if the tail call optimization failed. The MI level option was nixed immediately since it would require platform-specific pattern matching. The ISel level option was nixed because SelectionDAG only processes one IR level basic block at a time implying one could not create a DAG Combine to move the callinst.

To get around this problem:

  1. SelectionDAG can only process one block at a time, we can generate multiple machine basic blocks for one IR level basic block. This is how we handle bit tests and switches.
  2. At the MI level, tail calls are represented via a special return MIInst called "tcreturn". Thus if we know the basic block in which we wish to insert the stack protector check, we get the correct behavior by always inserting the stack protector check right before the return statement. This is a "magical transformation" since no matter where the stack protector check intrinsic is, we always insert the stack protector check code at the end of the BB.

Given the aforementioned constraints, the following solution was devised:

  1. On platforms that do not support ISel stack protector check generation, allow for the normal IR level stack protector check generation to continue.
  2. On platforms that do support ISel stack protector check generation:
    a. Use the IR level stack protector pass to decide if a stack protector is required/which BB we insert the stack protector check in by reusing the logic already therein.
    b. After we finish selecting the basic block, we produce the validation code with one of these techniques: 1) with a call to a guard check function 2) with inlined instrumentation
  1. We insert a call to the check function before the terminator.
  2. We first find a splice point in the parent basic block before the terminator and then splice the terminator of said basic block into the success basic block. Then we code-gen a new tail for the parent basic block consisting of the two loads, the comparison, and finally two branches to the success/failure basic blocks. We conclude by code-gening the failure basic block if we have not code-gened it already (all stack protector checks we generate in the same function, use the same failure basic block).

Definition at line 116 of file CodeGenCommonISel.h.