[PATCH] D84471: [X86] Fix for ballooning compile times due to Load Value Injection (LVI) mitigations

Scott Constable via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Jul 24 13:25:06 PDT 2020


sconstab added inline comments.


================
Comment at: llvm/lib/Target/X86/X86LoadValueInjectionLoadHardening.cpp:699-702
+      for (const auto *EgressEdge : EgressEdges)
+        EgressCutCost = std::max(EgressCutCost, EgressEdge->getValue());
+      for (const auto *IngressEdge : IngressEdges)
+        IngressCutCost = std::max(IngressCutCost, IngressEdge->getValue());
----------------
mattdr wrote:
> Two things:
> 1. What's the intuition for aggregating with "max" here rather than, say, summing the weights?
> 
> 2. It seems like we should be taking CutEdges into account somehow here. If we've already decided to cut an expensive edge, the *incremental* cost of cutting it again is zero and we shouldn't be including it here.
Thanks for pointing this out. I don't know why my intuition led me to use `std::max`. The minimum multi-cut algorithm would, in essence, also be adding the weights. And I think you're also correct that edges that have already been cut can be treated as having cost `0`.

I implemented these changes, and measured (1) a small decrease in the number of `LFENCE`s inserted, (2) no significant performance difference, and (3) no exposed LVI vulnerabilities.


================
Comment at: llvm/lib/Target/X86/X86LoadValueInjectionLoadHardening.cpp:706
+          IngressCutCost < EgressCutCost ? IngressEdges : EgressEdges;
+      llvm::for_each(EdgesToCut, [&](EdgeRef E) { CutEdges.insert(*E); });
     }
----------------
mattdr wrote:
> EdgeSet has `|=` for union, maybe that would be better here
`|=` is not overloaded for an array-like container on the RHS. Unless you think that `EdgesToCut` should also be a BitVector?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D84471/new/

https://reviews.llvm.org/D84471





More information about the llvm-commits mailing list