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

Fraser Cormack via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Mar 17 03:14:47 PDT 2022


frasercrmck added a comment.

In D121787#3388635 <https://reviews.llvm.org/D121787#3388635>, @lebedev.ri wrote:

> In D121787#3388573 <https://reviews.llvm.org/D121787#3388573>, @frasercrmck wrote:
>
>> 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 :)

I've updated the patch to do this now. No impact on any tests other than the one I added.

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

Yes I now see I misunderstood the semantics of non-integral pointer types. I thought they could be a different bitwidth than what they claimed to be which would have impacted GEP offsetting. But they're just about the bitwise representation.

> I don't follow. Performance in what sense?

I'm not sure exactly what, just picking up on @tra's comment and previous fix (why we didn't just use `addrspacecast` before). But like I said, if we find ourselves with a different AS to the original, musn't we have an addrspace cast in the original IR, so we're not introducing a new one? Therefore I don't think the cost of `addrspacecast` is important, and we already take the cost of the scalar-vs-vector load into account.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121787



More information about the llvm-commits mailing list