search for: constant_memory

...st 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. I guess targets would have to either...

...ocal. > > 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. > > I gue...

...ocal. > > 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-dependent manner. Currently, I can write IR that e...

...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-dependent manner. Curr...

...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-dependent manner...

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

...s 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 t...