[LLVMdev] Address space extension

[Micah Villmow]

It was commited at one point, however due to personal matters, I was not able to respond to issue that arose and the changes were reverted.
The longer explanation for why it was reverted can be read here:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-November/055098.html

Micah


> -----Original Message-----
> From: Michele Scandale [mailto:michele.scandale at gmail.com]
> Sent: Thursday, August 08, 2013 7:20 AM
> To: Micah Villmow
> Cc: Justin Holewinski; LLVM Developers Mailing List
> Subject: Re: [LLVMdev] Address space extension
> 
> On 08/08/2013 02:52 PM, Micah Villmow wrote:
> > This is something I proposed last year, so you might want to read up on that
> discussion first.
> >
> > You can find it here:
> > http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-September/053277.html
> 
> Uhm... I read the discussion, probably I've not understood the problem
> well: the conclusion (it has been committed?) is that to handle address space
> conversion that imply a change in the size of pointers must be expressed as a
> pair ptrtoint/inttoptr. What if the address space conversione logically change
> also the value of the pointer?
> 
> Indeed, trying to port that solution in the context of in-progress
> proposal: how to handle the fact that the addrspace information is logical? Is
> the frontend that need to produce the correct address space conversion?
> Why having an opaque instruction/generic-intrinsic that represent the
> conversion (what the conversion imply is target specific, so that each target
> should  lower this intrinsic using the knowledge of the source and destination
> address space) is bad?
> 
> Thanks again.
> 
> -Michele