search for: local_memory

...ou said earlier), but the backend just needs to know how to load/store a local. So perhaps the front-end should really be generating metadata which tells the target what address space it chose for a memory space. That is !private_memory = metadata !{ i32 0 } !global_memory = metadata !{ i32 1 } !local_memory = metadata !{ i32 2 } !constant_memory = metadata !{ i32 3 } Unfortunately you’d have to essentially reserve those metadata names for your use (better names than i chose of course), but this might be reasonable. You could alternately use the example I first gave, but just add a name field to it....

...needs to know how > to load/store a local. > > So perhaps the front-end should really be generating metadata which > tells the target what address space it chose for a memory space. That is > > !private_memory = metadata !{ i32 0 } > !global_memory = metadata !{ i32 1 } > !local_memory = metadata !{ i32 2 } > !constant_memory = metadata !{ i32 3 } > > Unfortunately you’d have to essentially reserve those metadata names for > your use (better names than i chose of course), but this might be > reasonable. You could alternately use the example I first gave, but >...

...just needs to know how to load/store a local. > > So perhaps the front-end should really be generating metadata which tells > the target what address space it chose for a memory space. That is > > !private_memory = metadata !{ i32 0 } > !global_memory = metadata !{ i32 1 } > !local_memory = metadata !{ i32 2 } > !constant_memory = metadata !{ i32 3 } > This is specific to an OpenCL front-end. How would this translate to a language with a different memory hierarchy? I would also like to preserve the ability for front-ends to directly assign address spaces in a target-depende...

...d/store a local. > > So perhaps the front-end should really be generating metadata which > tells the target what address space it chose for a memory space. > That is > > !private_memory = metadata !{ i32 0 } > !global_memory = metadata !{ i32 1 } > !local_memory = metadata !{ i32 2 } > !constant_memory = metadata !{ i32 3 } > > > This is specific to an OpenCL front-end. How would this translate to a > language with a different memory hierarchy? > > I would also like to preserve the ability for front-ends to directly > assign ad...

...re a local. > > > > So perhaps the front-end should really be generating metadata which tells > > the target what address space it chose for a memory space. That is > > > > !private_memory = metadata !{ i32 0 } > > !global_memory = metadata !{ i32 1 } > > !local_memory = metadata !{ i32 2 } > > !constant_memory = metadata !{ i32 3 } > > > > This is specific to an OpenCL front-end. How would this translate to a > language with a different memory hierarchy? > > I would also like to preserve the ability for front-ends to directly assign...

On 08/08/2013 03:16 AM, Pete Cooper wrote: > > On Aug 7, 2013, at 5:12 PM, Michele Scandale <michele.scandale at gmail.com> wrote: > >> 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

On Aug 7, 2013, at 5:12 PM, Michele Scandale <michele.scandale at gmail.com> wrote: > 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

...d/store a local. >> >> So perhaps the front-end should really be generating metadata which >> tells the target what address space it chose for a memory space. That is >> >> !private_memory = metadata !{ i32 0 } >> !global_memory = metadata !{ i32 1 } >> !local_memory = metadata !{ i32 2 } >> !constant_memory = metadata !{ i32 3 } >> >> Unfortunately you’d have to essentially reserve those metadata names for >> your use (better names than i chose of course), but this might be >> reasonable. You could alternately use the example I...