[LLVMdev] Address space extension

Michele Scandale michele.scandale at gmail.com
Wed Aug 7 17:12:03 PDT 2013


On 08/08/2013 02:02 AM, Justin Holewinski wrote:
> This worries me a bit.  This would introduce language-specific
> processing into SelectionDAG.  OpenCL maps address spaces one way, other
> languages map them in other ways.  Currently, it is the job of the
> front-end to map pointers into the correct address space for the target
> (hence the address space map in clang).  With (my understanding of) this
> proposal, there would be a pre-defined set of language-specific address
> spaces that the target would need to know about. IMO it should be the
> job of the front-end to do this mapping.

The begin of the discussion was about possible way to represent high 
level address space information in the IR different from target address 
spaces (to have the information orthogonally respect the mapping so to 
handle also those targets that have the trivial mapping).

My interpretation of the solution proposed by Pete is that the frontend 
emits metadata that describe address spaces (overlapping information and 
mapping target specific). The instruction selection simply applis the 
mapping encoded in the metadata. So there is no pre-defined set, but 
there is only a mapping algorithm implemented in the instruction 
selection phase "table driven", the table is encoded as metadata.



More information about the llvm-dev mailing list