markus added a comment. In D123300#3459023 <https://reviews.llvm.org/D123300#3459023>, @nikic wrote:
> @markus Without tracing through it in detail, I'd guess that without opaque > pointers this creates two getelementptr constant expressions that get folded > together. With opaque pointers, the first one (which would be a zero-index > GEP) is omitted, and only the second one is left. ConstantFolding will later > canonicalize the GEP source type, but this only happens when InstCombine > runs, while you're looking at unoptimized IR. Yes, that appears to have been the case. Thanks for explaining. > Are you encountering some particular issue relating to this? For well-written > optimizations, the exact GEP representation shouldn't matter either way. One of our target specific passes ran into problems with this as it made some assumptions that no longer hold with opaque pointers. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D123300/new/ https://reviews.llvm.org/D123300 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
