search for: private_memory

...ress space. We know the front-end is really going to choose 2 (from what you 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 al...

...se 2 (from what you > > 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 } > > > > This is specific to an OpenCL front-end. How would this translate to a > language with a different memory hier...

...d is really going to choose > 2 (from what you 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...

...nt-end is really going to choose 2 (from what you > 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 } > 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 preser...

...choose 2 (from what you 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 } > > > This is specific to an OpenCL front-end. How would this translate to a > language with a different memory hierarchy? &g...

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

...t;> 2 (from what you 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 o...