================
@@ -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
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

Reply via email to