[PATCH] D78391: [ValueLattice] Allow two range extensions.

Nikita Popov via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Apr 21 11:52:48 PDT 2020


nikic added inline comments.


================
Comment at: llvm/include/llvm/Analysis/ValueLattice.h:358
       // otherwise.
-      if (Opts.CheckWiden && ++NumRangeExtensions >= 1) {
+      if (Opts.CheckWiden && ++NumRangeExtensions >= 2) {
         // Make sure WidenCR is only used if it contains the merge result.
----------------
Add `MaxRangeExtensions = 2` static const?


================
Comment at: llvm/test/Transforms/SCCP/constant-range-struct.ll:106
+; CHECK-NEXT:    call void @use(i1 true)
+; CHECK-NEXT:    call void @use(i1 true)
 ; CHECK-NEXT:    [[T_3:%.*]] = icmp ne i64 [[V2]], 0
----------------
Disclaimer: First time I'm looking at SCCP in LLVM.

I feel like we really should be handling this already, without support for multiple widenings (and also, we should handle this for cases with more phi arguments). What happens in `@struct2` is that we first visit the entry block, then the `false` block, then the `exit` block (computing everything there), then the `true` block, then `true -> exit` becomes feasible and we update the phi constant ranges, and then merge in new values for all instructions in `exit`, going to overdefined (without widening).

If we had instead visited `entry`, `false`, `true`, `exit`, then not only would we have saved on duplicate computations, we would have also avoided the need to perform widening.

I feel like the right way to approach this is to fix the block visitation order, and then more widening is something we can do on top of that (which should then only matter for loops).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78391





More information about the llvm-commits mailing list