[LLVMdev] Address space extension

[Michele Scandale]

(The previous sent message had some issues...)

----------------------------------------------

Hello to everybody,

I just want make a quick summary:

OBJECTIVE: discuss for finding a way to represent logical (derived from
source language abstractions) address space also in the IR to be able to
exploit this information for optimizations.

CURRENT STATE:
The partial workaround probably used IMO is: use custom address spaces
(the semantic 'addrspace' modifier is a target-specific) so that in the
IR I still have this knowledge and "cross-fingers" for the code
generation (implicit assumption, backends with no different physical
address spaces generally ignore this information).
In the middle-end the information may be used, in the backend the only
knowledge is indirect for those load/store instructions that are still
linked to an IR Value*.

MY CRITIC TO THE CURRENT STATE:
'addrspace' modifier is not used correctly, crossing fingers hoping that
everything would be fine in the backend is not generally acceptable: I
would like a mapping explicit phase (for a specific target may be a
NO-OP phase) with a verification of consistency. Considering the case of
targets with an unique address space, I still would like to exploit high
level informations about address spaces for optimizations.

TEMP PROPOSAL
*logical address spaces relationships*: using TBAA style metadata, this
would allow to improve the alias analysis and know some features of
logical address spaces e.g. constant space for LICM.

*mapping information*:
a) use metadata -- but from metadata should not depend the correctness
b) something like data layout string -- still not discussed, but it
exposes a static property in the IR making it totally target dependent
c) encoding the mapping in backends -- IMO a bad idea because backend
would be language aware
d) backends expose address spaces detailed description to allow high
layer (the frontend) to make the mapping description based -- I don't
see how to handle cases with only one physical address space
e) create a language descriptive pass that is responsible to handle
language specific and target dependent information like address space
mapping -- a design issue is that the compiler pipeline will depend on a
language specific pass, there would be possible issue with independent
tools like opt, llc, etc... waiting some feedback

RELATED PROBLEMS
1) addrspacecast support: approved but not implemented yet. It will
cleanup address spaces conversions localized in a single instruction
allowing each target to define the semantic...
2) code generator does not support different pointer types (at least one
for each physical address space).


Something missing or incorrect or wrong? Opinions?

Thanks in advance to everybody.

-Michele