[PATCH] D94355: [SimplifyCFG] Add relative switch lookup tables

Hans Wennborg via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Jan 15 01:32:51 PST 2021


hans added inline comments.


================
Comment at: llvm/lib/Transforms/Utils/SimplifyCFG.cpp:5469
+  /// Otherwise, returns false.
+  static bool ShouldBuildRelLookupTable(
+      const SmallVectorImpl<std::pair<ConstantInt *, Constant *>> &Values);
----------------
Since this is a helper function used internally by the class, it should be private.


================
Comment at: llvm/lib/Transforms/Utils/SimplifyCFG.cpp:5473
+  /// Generate an offset between the lookup table and given case result.
+  static Constant *GenerateRelOffset(GlobalVariable *Array, Constant *CaseRes,
+                                     IRBuilder<> &Builder);
----------------
Actually, this should probably be private too.


================
Comment at: llvm/lib/Transforms/Utils/SimplifyCFG.cpp:5701
+                                               IRBuilder<> &Builder) {
+  Constant *Base = llvm::ConstantExpr::getPtrToInt(Array, Builder.getInt64Ty());
+  Constant *Target =
----------------
It's a little annoying that we have to pass in a Builder here (and also to the SwitchLookupTable class) just to create integer types. I don't think a builder is strictly necessary for that.

But more importantly, I'm not sure hard-coding this to 64 bits for the pointer and 32 bits for the offset is correct. Shouldn't this depend on the target?


================
Comment at: llvm/lib/Transforms/Utils/SimplifyCFG.cpp:5740-5747
+    // Make sure the table index will not overflow when treated as signed.
+    IntegerType *IT = cast<IntegerType>(Index->getType());
+    uint64_t TableSize =
+        RelOffsetArray->getInitializer()->getType()->getArrayNumElements();
+    if (TableSize > (1ULL << (IT->getBitWidth() - 1)))
+      Index = Builder.CreateZExt(
+          Index, IntegerType::get(IT->getContext(), IT->getBitWidth() + 1),
----------------
leonardchan wrote:
> Nit: Since this seems to be the exact same as the start of the `ArrayKind` case, it might be cleaner to move this into a lambda or function.
One alternative would also be to bake the cases together:

```
case ArrayKind:
case RelOffsetArrayKind: {
... common stuff ...
if (Kind == RelOffsetArrayKind) {
  .. special stuff ..
}
```



================
Comment at: llvm/test/Transforms/SimplifyCFG/ARM/switch-to-relative-lookup-table.ll:1
+; NOTE: Assertions have been autogenerated by utils/update_test_checks.py
+; RUN: opt -S -simplifycfg -simplifycfg-require-and-preserve-domtree=1 -switch-to-lookup -relative-switch-lookup-table -mtriple=arm -relocation-model=pic       < %s | FileCheck %s
----------------
gulfem wrote:
> hans wrote:
> > Any reason to have tests both under ARM/ and X86/ for this?
> > 
> > Also I'd like to see a test which shows that the transformation happens for PIC code but not for non-PIC.
> > Any reason to have tests both under ARM/ and X86/ for this?
> There are two existing switch-to-lookup tests one under ARM/ and one under /X86 (I don't know the original reason).
> /ARM test is much simpler. I now put all the relative lookup tests under /X86.
> 
> > Also I'd like to see a test which shows that the transformation happens for PIC code but not for non-PIC.
> Could you please clarify that? 
> Do you want to see a test that checks the code for non-PIC case when -fno-PIC is enabled?
> 
> 
> Do you want to see a test that checks the code for non-PIC case when -fno-PIC is enabled?

Yes, exactly. This seems important since we don't want the transformation to run for the no-PIC case (and currently I don't see anything in the code which ensures that.)

It might help to put the relative lookup table test in a separate file, and use two invocations once with PIC and one without, and check the expected results with different FileCheck prefixes.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94355



More information about the llvm-commits mailing list