[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