This is an archive of the discontinued LLVM Phabricator instance.

Handle ptrtoint in InferAddressSpace
AbandonedPublic

Authored by gangche1 on Jan 17 2020, 11:20 AM.

Details

Reviewers
hliao
arsenm
Summary

We see in our IR that has addrspacecast before ptrtoint, which requires this optimization. Therefore suggest to add the handling of ptrtoint.

Diff Detail

Event Timeline

gangche1 created this revision.Jan 17 2020, 11:20 AM

We see in our IR that has addrspacecast before ptrtoint, which requires this optimization. Therefore suggest to add the handling of ptrtoint.

arsenm requested changes to this revision.Jan 17 2020, 11:30 AM
arsenm added a subscriber: arsenm.

This is incorrect and assumes the address spaces have equivalent bit representations

This revision now requires changes to proceed.Jan 17 2020, 11:30 AM

inttoptr and ptrtoint should be treated as opaque ones. If needed, they should be handled with target-specific. This pass is definitely not the place to handle them.

We see in our IR that has addrspacecast before ptrtoint, which requires this optimization. Therefore suggest to add the handling of ptrtoint.

inttoptr and ptrtoint should be treated as opaque ones. If needed, they should be handled with target-specific. This pass is definitely not the place to handle them.

We see in our IR that has addrspacecast before ptrtoint, which requires this optimization. Therefore suggest to add the handling of ptrtoint.

This is backwards, inttoptr/ptrtoint are "copies" that may truncate or trivially extend. addrspacecast is the opaque part

hliao added a comment.Jan 18 2020, 7:44 AM

inttoptr and ptrtoint should be treated as opaque ones. If needed, they should be handled with target-specific. This pass is definitely not the place to handle them.

We see in our IR that has addrspacecast before ptrtoint, which requires this optimization. Therefore suggest to add the handling of ptrtoint.

This is backwards, inttoptr/ptrtoint are "copies" that may truncate or trivially extend. addrspacecast is the opaque part

Thanks for correcting me. What I really mean is that that "copies" are opaque and you cannot interpret them the same as addrspacecast. They are different in semantics.

What if I add another query in TTI, check if an address space has the same bit-pattern as the flat-address, then handle the ptrtoint with this extra condition?

What if I add another query in TTI, check if an address space has the same bit-pattern as the flat-address, then handle the ptrtoint with this extra condition?

What is the problem you are really trying to solve? There's already a isNoopAddrspaceCast hook

isNoopAddrspaceCast is what I am looking for. Could I use that in this InferAddressSpace pass to get rid of a NoopAddrSpaceCast that is used by ptrtoint?

isNoopAddrspaceCast is what I am looking for. Could I use that in this InferAddressSpace pass to get rid of a NoopAddrSpaceCast that is used by ptrtoint?

Maybe, but I'm wondering why you have noop addrspacecasts in the first place. This seems like a problem you shouldn't have to solve

how do I withdraw this review?

how do I withdraw this review?

There's an abandon revision. We also now do recognize certain ptrtoint/inttoptr pairs, although this is somewhat questionable

gangche1 abandoned this revision.Aug 27 2020, 8:36 AM