[PATCH] D121787: [VectorCombine] Avoid crossing address space boundaries

[Roman Lebedev via Phabricator via llvm-commits]

lebedev.ri added a comment.

In D121787#3388573 <https://reviews.llvm.org/D121787#3388573>, @frasercrmck wrote:

> In D121787#3387186 <https://reviews.llvm.org/D121787#3387186>, @lebedev.ri wrote:
>
>> Does adding an offset of `i32 %x` bytes do the same thing to the pointer regardless of the address space?
>> Can't we just emit said missing ASC?
>
> That was my initial thought. I don't see why we're forced into a `bitcast` when we have `addrspacecast`. But given the original fix kept us down the `bitcast` lines, I assumed there must be something I'm missing.
>
> AFAICT, address spaces have no effect on GEPs <https://llvm.org/docs/GetElementPtr.html#what-effect-do-address-spaces-have-on-geps>.

Then let's just emit said ASC :)

> But then again, are non-integral pointer types <https://llvm.org/docs/LangRef.html#nointptrtype> a concern?

We don't do any integers<->pointers casts here, so i don't see why it would be?

> There may well be a question of performance, as @tra seems to imply,

I don't follow. Performance in what sense?

> and that's why we don't issue `addrspacecast`s. Obviously if we find ourselves in this situation there's already some kind of cast going on. But it's possible that a load from one address space is much worse than a load from the original address space. `isNoopAddrSpaceCast` is an easy win in any case, as @tra points out.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121787