[llvm-dev] [InstCombine] addrspacecast assumed associative with gep

Matt Arsenault via llvm-dev llvm-dev at lists.llvm.org
Tue Jun 11 16:10:25 PDT 2019



> On Jun 10, 2019, at 9:43 PM, via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> The following combine(-enabling transformation) makes me uncomfortable:
> 
>   gep(addrspacecast(gep p0) to p1)
> 
>   addrspacecast(gep(gep p0)) to p1
> 
> It's applied at visitAddrSpaceCast in InstCombineCasts.cpp.
> 
> Before this, I'd always assumed address spaces were very much "user domain". Datalayout even supports marking a space as "non-integral", to designate that manipulation as bits is impossible. In my case, I have a different byte width in p1 over p0 (I know - but we all knew it was coming). All of p0 can be addressed in p1, but the reverse transformation is only sometimes possible as GEPs behave differently on the other side of the cast. This transformation of course breaks that.

What do you mean exactly by "behave differently on the other side of the cast”?  Do you have a concrete example?

Questions about what’s allowed with addrspacecast arithmetic have come up before (e.g. https://reviews.llvm.org/D31924 <https://reviews.llvm.org/D31924>) but it’s never really converged into explicit guidance for the LangRef. Is this with a non-integral address space? I would like to make the LangRef clearer on what’s allowed and what’s not. Having some concrete examples would be helpful to clarify this, and possibly remove the combine.

-Matt


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190611/1514606a/attachment.html>


More information about the llvm-dev mailing list