[LLVMdev] Address space extension

[Iain Sandoe]

Hello all .. my first post to this thread (and this list, as it happens)..

On 10 Aug 2013, at 07:46, Michele Scandale wrote:

> I just want make a quick summary:

a summary is indeed useful.

> 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.

Seems an excellent objective.

It would seem to me that there are two (potentially overlapping, but distinct) pieces of information, 

A. The FE language rules for the semantics of whatever address spaces it defines (which might even vary depending on compile-flags - e.g. a flag introducing some language-defined parallel shared space).  Certainly these rules will vary in interesting and non-obvious ways between different languages.

B. The target's definition of the physical address spaces that it provides, and the rules that apply for determining interactions between these. 

[It is agreed that address space attribute markup allows one to indicate (B) to the FE - but, as I understand things, the FE merely passes that information along at present**, and there is no way to specify the rules for operations between spaces]

.. please forgive me if I'm restating things (or have missed a vital point) - but trying to summarise in my own head:

My concern is that in order that the IR / optimisers remain agnostic to both target and FE these two pieces would seem ideally provided separately?

that is the IR / optimisers need the union of those two pieces of information - trying to amalgamate them seems risky, it would appear cleaner to specify them independently.

FWIW, I completely concur with the need for type info on pointers - for my use-case it would be helpful too.

> 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...

Is anyone known to be working on this?

> 2) code generator does not support different pointer types (at least one
> for each physical address space).

this is a very useful capability .... even without (1) and the disussion above.

( It is not my intention to hijack this thread )
- but I'd like to get some clarification on where we are with this and what's needed to move forward.

I have an out-of-tree port that would (very much) like to make use of address-spaces - but can't until this is working.

 - characteristics share some features with other posters on this thread:

 * different sized address regs
 * most address regs are larger than int regs
 * address regs only support a sub-set of operations
 * some address spaces are disjoint, some may overlap.

so far, I declared a data layout with  "-p0:xx:yy-pp1:zz:aa-p2:... "  etc.
... implemented getPointerWidthV() (and getPointerRegClass(), which never seems to get called).

I see that global data items are correctly sized according to my pointer definitions - but that all operations are carried out as if pointers were sized for address space 0.

What is required to (at minimum) get the different size pointers working?

Whilst the points at (1) above are completely agreed - one can make good progress by starting with (2) - and making it the User's responsibility to obey the casting and overlap rules whilst (1) is implemented.

So .. (perhaps this should be a new thread) -
 I'd like to understand what is needed (in the short-term) to do:
 (2) then (1) ..  
 is it a question of updating Micah's patch (for 2) .. and starting from scratch for (1)?

thanks
Iain