LLVM 22.0.0git
GuardWidening.cpp File Reference

Go to the source code of this file.

Macros

#define DEBUG_TYPE   "guard-widening"

Functions

 STATISTIC (GuardsEliminated, "Number of eliminated guards")
 STATISTIC (CondBranchEliminated, "Number of eliminated conditional branches")
 STATISTIC (FreezeAdded, "Number of freeze instruction introduced")
static ValuegetCondition (Instruction *I)
static void setCondition (Instruction *I, Value *NewCond)
static void eliminateGuard (Instruction *GuardInst, MemorySSAUpdater *MSSAU)
static std::optional< BasicBlock::iteratorfindInsertionPointForWideCondition (Instruction *WCOrGuard)
 Find a point at which the widened condition of Guard should be inserted.
static bool isSupportedGuardInstruction (const Instruction *Insn)
static std::optional< BasicBlock::iteratorgetFreezeInsertPt (Value *V, const DominatorTree &DT)

Variables

static cl::opt< boolWidenBranchGuards ("guard-widening-widen-branch-guards", cl::Hidden, cl::desc("Whether or not we should widen guards " "expressed as branches by widenable conditions"), cl::init(true))

Macro Definition Documentation

◆ DEBUG_TYPE

#define DEBUG_TYPE   "guard-widening"

Definition at line 66 of file GuardWidening.cpp.

Function Documentation

◆ eliminateGuard()

void eliminateGuard ( Instruction * GuardInst,
MemorySSAUpdater * MSSAU )
static

◆ findInsertionPointForWideCondition()

std::optional< BasicBlock::iterator > findInsertionPointForWideCondition ( Instruction * WCOrGuard)
static

Find a point at which the widened condition of Guard should be inserted.

When it is represented as intrinsic call, we can do it right before the call instruction. However, when we are dealing with widenable branch, we must account for the following situation: widening should not turn a loop-invariant condition into a loop-variant. It means that if widenable.condition() call is invariant (w.r.t. any loop), the new wide condition should stay invariant. Otherwise there can be a miscompile, like the one described at https://github.com/llvm/llvm-project/issues/60234. The safest way to do it is to expand the new condition at WC's block.

Definition at line 123 of file GuardWidening.cpp.

References llvm::cast(), llvm::extractWidenableCondition(), llvm::ilist_node_impl< OptionsT >::getIterator(), and llvm::isGuard().

◆ getCondition()

◆ getFreezeInsertPt()

◆ isSupportedGuardInstruction()

bool isSupportedGuardInstruction ( const Instruction * Insn)
static

◆ setCondition()

void setCondition ( Instruction * I,
Value * NewCond )
static

Definition at line 95 of file GuardWidening.cpp.

References assert(), llvm::cast(), llvm::dyn_cast(), and I.

◆ STATISTIC() [1/3]

STATISTIC ( CondBranchEliminated ,
"Number of eliminated conditional branches"  )

◆ STATISTIC() [2/3]

STATISTIC ( FreezeAdded ,
"Number of freeze instruction introduced"  )

◆ STATISTIC() [3/3]

STATISTIC ( GuardsEliminated ,
"Number of eliminated guards"  )

Variable Documentation

◆ WidenBranchGuards

cl::opt< bool > WidenBranchGuards("guard-widening-widen-branch-guards", cl::Hidden, cl::desc("Whether or not we should widen guards " "expressed as branches by widenable conditions"), cl::init(true)) ( "guard-widening-widen-branch-guards" ,
cl::Hidden ,
cl::desc("Whether or not we should widen guards " "expressed as branches by widenable conditions") ,
cl::init(true)  )
static