[LLVMdev] Casting between address spaces and address space semantics

[Matthijs Kooijman]

Hi Eli, Mon Ping,


> In ISO/IEC WG14 n1169 on the C extensions to support embedded  
> processors, any two address spaces must be disjoint, must be  
> equivalent, or must be nested.  

Ah, that standard is a lot clearer on this subject than the DSP-C one I read
was.

> As Eli indicated, the actual  relationship is platform specific depending on
> what makes the most  sense for your hardware and how the program will behave
> will depend on  that relationship.
If I read the standard correctly, the properties of these address spaces can
be fully captured by defining the relationship between every pair of address
spaces (disjoint, identical, subset/superset).

I think it would make sense to make these relationships backend/platform
specific, but for clang and the optimization passes to properly work with
address spaces, these relationships should be known. It seems to me that the
proper way to handle this, is to include this information in the TargetData
class (or whatever platform-specific class is appropriate, I'm not really into
this currently).

When this information is known, we can define a "any memory" address space,
which is a superset of the specific address spaces. This will allow a function
to be (temporarily) defined to work with any memory, while still properly
propagating information about the different memories through the program (and
preventing mixup, since you can cast to the "any memory" address space, but
not back).

This requires clang to know about the relationships between address spaces, so
it knows when to insert implicit casts and when to error out.

This also requires the transformation passes to know about these
relationships, so they know when a bitcast can be removed and types
propagated.


So, is it a plan to make these relationships available to the
frontend/transformations in some way? If so, in what way?

Gr.

Matthijs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080718/5bf51108/attachment.sig>