[LLVMdev] FW: RFC: Supporting different sized address space arithmetic

Villmow, Micah Micah.Villmow at amd.com
Thu Aug 30 15:27:08 PDT 2012



> -----Original Message-----
> From: Eli Friedman [mailto:eli.friedman at gmail.com]
> Sent: Thursday, August 30, 2012 3:03 PM
> To: Villmow, Micah
> Cc: LLVM Developers Mail
> Subject: Re: [LLVMdev] FW: RFC: Supporting different sized address space
> arithmetic
> 
> On Thu, Aug 30, 2012 at 2:38 PM, Villmow, Micah <Micah.Villmow at amd.com>
> wrote:
> > Eli,
> >  Here is an updated patch. This is a lot smaller based on your
> feedback and still solves the same problem.
> 
> The patch appears to be corrupt; can you regenerate it?
[Villmow, Micah] Attached.
> 
> > For your comment on the IR changes, I'm reluctant to introduce changes
> there because really the backend is overriding the default behavior at a
> device specific level. The optimizations themselves can be dangerous,
> but still should produce correct results, this only allows the backend
> to optimize certain cases and is opt-in.
> 
> Suppose I have an array of ten pointers into some address-space which
> uses 16-bit pointers, and the default pointer size is 64 bits.  How many
> bytes in memory does that take?  To me, it seems like the obvious answer
> is 20 bytes, but if you compute it using our current TargetData, you'll
> come up with an answer of 80.  That can't work.
> 
> If your answer is that it should be 80, and the size of a pointer isn't
> something the frontend/IR optimizers should be aware of, I'm not sure
> your approach makes sense; you could just introduce custom load/store
> nodes in your target which truncate the pointer, and you wouldn't need
> to mess with the size of a pointer at all.
[Villmow, Micah] Yeah I see your point here. I don't deal with array of pointers in OpenCL, so didn't think of this case.

So, what about extending data layout to support something like:
p#:size:abi:pref <- specify the size, abi and preference for the pointer of address space '#'. Default behavior is p:size:abi:pref.

I think I could throw this together and get back to you within a week or so, but need to look into the code more to see how much work it would be.
Doing it this way might actually remove the need to make some of the changes I made as it becomes a more of a core LLVM issue and less of a codegen issue.
> 
> -Eli

-------------- next part --------------
A non-text attachment was scrubbed...
Name: addr_space_variable_pointer.patch
Type: application/octet-stream
Size: 7356 bytes
Desc: addr_space_variable_pointer.patch
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120830/8953464b/attachment.obj>


More information about the llvm-dev mailing list