================
@@ -355,6 +389,46 @@ class SrcSafetyAnalysis {
return Regs;
}
+ // Returns all registers made trusted by this instruction.
+ SmallVector<MCPhysReg> getRegsMadeTrusted(const MCInst &Point,
+ const SrcState &Cur) const {
+ SmallVector<MCPhysReg> Regs;
+ const MCPhysReg NoReg = BC.MIB->getNoRegister();
+
+ // An authenticated pointer can be checked, or
+ MCPhysReg CheckedReg =
+ BC.MIB->getAuthCheckedReg(Point, /*MayOverwrite=*/false);
+ if (CheckedReg != NoReg && Cur.SafeToDerefRegs[CheckedReg])
+ Regs.push_back(CheckedReg);
+
+ if (CheckerSequenceInfo.contains(&Point)) {
+ MCPhysReg CheckedReg;
+ const MCInst *FirstCheckerInst;
+ std::tie(CheckedReg, FirstCheckerInst) = CheckerSequenceInfo.at(&Point);
+
+ // FirstCheckerInst should belong to the same basic block, meaning
+ // it was deterministically processed a few steps before this
instruction.
+ const SrcState &StateBeforeChecker =
+ getStateBefore(*FirstCheckerInst).get();
----------------
kbeyls wrote:
This is a nitpick.
I was trying to get my head around whether it's guaranteed to get to a fixed
point in a dataflow analysis, where next to using just the previous state on
the current instruction, also a state on another instruction is used as input
to compute the next state for the current instruction.
I'm assuming this is probably fine (probably, because as you write in the
comment, this instruction should be in the same basic block).
I thought I'd just ask if you ended up checking this somewhere else and, if so,
you'd happen to have a pointer to something stating that you can also take
state from another instruction in the same basic block, and still be guaranteed
to reach a fixed point in a dataflow analysis?
Orthogonal to that: would it be hard to add an assert here that
`*FirstCheckerInst` is indeed in the same basic block?
https://github.com/llvm/llvm-project/pull/134146
_______________________________________________
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
