[flang-commits] [llvm] [flang] [clang] [InstCombine] Canonicalize constant GEPs to i8 source element type (PR #68882)
Bruno De Fraine via flang-commits
flang-commits at lists.llvm.org
Tue Jan 9 01:17:53 PST 2024
================
@@ -2282,6 +2282,15 @@ Instruction *InstCombinerImpl::visitGetElementPtrInst(GetElementPtrInst &GEP) {
if (MadeChange)
return &GEP;
+ // Canonicalize constant GEPs to i8 type.
----------------
brunodf-snps wrote:
Reading about the [planned steps](https://www.npopov.com/2024/01/01/This-year-in-LLVM-2023.html#ptradd) to move from getelementptr to ptradd, I would appreciate the opportunity to **not** add more hardcoded instances of i8 (i.e. `isIntegerTy(8)` or `getInt8Ty` below) in this effort. You don't need an 8 bit container, you want the canonical type that has getTypeStoreSize(Ty) == 1, it would be much better if there was a minimal API that is just a slight abstraction over i8 but that makes this goal apparent. (I would personally use something with the terminology "addressable unit type", so "isAddressableUnitType", "getAddressableUnitType" etc.)
For context, we are also a downstream user in architectural contexts with memories that are not byte addressable. This can be a main memory that is word addressable and does not have byte or sub-word access (so the canonical unit type is naturally i16 or i24... although i8 would still work), but also additional memories that cannot hold integers at all, for example, a separate memory (address space) for vectors (the canonical unit type is a vector and i8 is not storable in that memory/address space). Whenever there are hardcoded instances of i8 in the code base, we typically have to review them in our tree (yes, SCEVExpander). But it makes a difference whether the code is assuming an 8 bit container, or just needs a type with getTypeStoreSize(Ty) == 1.
https://github.com/llvm/llvm-project/pull/68882
More information about the flang-commits
mailing list