[PATCH] D103503: [OpaquePtr] Introduce option to force all pointers to be opaque pointers

David Blaikie via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Jun 2 09:25:36 PDT 2021


dblaikie added inline comments.


================
Comment at: llvm/lib/Bitcode/Writer/ValueEnumerator.cpp:366-389
   // Enumerate the global variables.
-  for (const GlobalVariable &GV : M.globals())
+  for (const GlobalVariable &GV : M.globals()) {
     EnumerateValue(&GV);
+    EnumerateType(GV.getValueType());
+  }
 
   // Enumerate the functions.
----------------
Looks like maybe only one of these code changes is tested - perhaps the test should be expanded to have an example of each of these to exercise each fix here? (maybe in separate patches)


================
Comment at: llvm/test/Other/force-opaque-ptrs.ll:5-7
+define i32* @f(i32* %a) {
+  ret i32* %a
+}
----------------
Would this still exercise the desired codepath if the function was `void()` instead of `ptr(ptr)`? (if I'm understanding correctly, the interesting issue is that the type of `f` itself becomes an opaque pointer - so, oh, you need /some/ interesting type in the function type that would be missed, yeah? What about `void(i32)` would that still reveal the issue/validate the fix?)

I ask because it might be more clear which pointer type becoming opaque is the interesting one?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103503



More information about the llvm-commits mailing list