[PATCH] D87827: [SCEVExpander] Support expanding nonintegral pointers with constant base.
Eli Friedman via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu Sep 17 14:09:53 PDT 2020
efriedma added a comment.
I have a proposal in https://bugs.llvm.org/show_bug.cgi?id=46786#c20 which would solve this, among other issues. Not sure when I'll get around to actually implementing it.
================
Comment at: llvm/lib/Transforms/Utils/ScalarEvolutionExpander.cpp:134
+ // the reminder of the division will be stripped.
+ if (Op == Instruction::IntToPtr && DL.isNonIntegralPointerType(PtrTy)) {
+ auto *Idx = Builder.CreateUDiv(
----------------
fhahn wrote:
> arsenm wrote:
> > It seems broken that getCastOpcode would return IntToPtr in a situation where it's illegal
> Yes, that seems a rather big hole in getCastOpcode unfortunately and should probably also be changed.
>
> But I think the key question is how to best deal with the problem during SCEV expansion here, because AFAIK we do not have a way to indicate that we failed to expand an expression in the expander.
>
> Is it enough to emit a `GEP` with a computed index? Or should we better try to get a type with an alloc size of 1 byte and use that? I guess there could be configurations which do not have such a type, not sure what to do then.
In general, for non-null pointers, SCEVExpander uses a GEP over i8* (in the appropriate address space). We should do that even if the implicit null is missing. The offset isn't necessarily divisible by the element type: SCEV looks through bitcasts.
> I guess there could be configurations which do not have such a type
i8 is always one byte. (This should be true even with an out-of-tree patchset that makes bytes bigger than 8 bits: it would just be a non-byte-sized type, similar to i1.)
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D87827/new/
https://reviews.llvm.org/D87827
More information about the llvm-commits
mailing list