[PATCH] Address Space Casting

David Chisnall David.Chisnall at cl.cam.ac.uk
Thu Aug 15 01:05:13 PDT 2013


On 14 Aug 2013, at 20:06, Matt Arsenault <Matthew.Arsenault at amd.com> wrote:

> I think ptrtoint / inttoptr method would be acceptable, at least for some targets. It sounded like David had some weird case that might not work with this. If the only real problem was turning ptrtoint-inttoptr into bitcasts between different sized address spaces, then that should be fixed (and probably already is).

The problem with inttoptr of ptrtoint is that the semantics are unclear and it's hard to do sensible things with them in either the middle or back ends of the compiler.  The middle needs to know if the address spaces are disjoint so that it can tell whether the result will give something invalid, something valid but with possible strange aliasing, or something sensible.  With an explicit address space cast, we get a clear indication in the middle that the origin and result are the same object (or one is a valid object and the other is invalid).

The rationale for disallowing it was that the verifier would tell us if a transform is adding some invalid or dangerous operations.  The ptrtoint inttoptr sequence is particularly insidious because it may or may not give sensible results, depending on the target, and it does so in a way that makes it very difficult for the target to reject invalid transforms.  For the simple example of x86, you want to be able to explicitly disallow casts between address spaces 0, 256, and 257.  This is easy to do if the back end is guaranteed to always get an address space cast node in the SelectionDAG, and it's easy for an earlier pass to check for if it is always an address space cast in the IR.  

Ideally, we'd expose methods in the target information telling us:

- Are casts from address space N to address space M allowed (this is not always the same in both directions - we have two address spaces where casts in one direction are always valid but casts in the other may not be)
- How big is a pointer in a given address space (this is already present, I believe)
- How big is the address component of a pointer in a given address space (this is equal to the size of the pointer for simple pointer types)

I'll try to do a more detailed review of the patches this week.

David





More information about the llvm-commits mailing list