search for: memfenc

...OK since it’s constant. Private address space is supposed to be totally inaccessible from other workitems, so parallel modifications aren’t a concern. The others require explicit synchronization which noalias would need to be aware of. >>> FWIW, it seems generally useful to me to have a nomemfence function attribute and intrinsic property. We should avoid memory optimization (and possibly other optimization) across these regardless of alias analysis. >>> >> I'm think I'll try implementing this. Ideally it would be parameterized over the address space, so it makes more...

...since it’s constant. Private address space is supposed to be totally inaccessible from other workitems, so parallel modifications aren’t a concern. The others require explicit synchronization which noalias would need to be aware of. >>>> FWIW, it seems generally useful to me to have a nomemfence function attribute and intrinsic property. We should avoid memory optimization (and possibly other optimization) across these regardless of alias analysis. >>>> >>> I'm think I'll try implementing this. Ideally it would be parameterized over the address space, so it m...

On Dec 26, 2013, at 10:38 PM, Andrew Trick <atrick at apple.com> wrote: >> >> >> I think "memfence" could be an issue if we use the attribute to summarize LLVM atomic load/store and fence instructions (in addition to OpenCL barriers). >> >> I have no idea what semantics you would attach to it in this case. I've not seen any clear explanation of such semantics yet in this t...

...e it’s constant. Private address space is supposed to be totally inaccessible from other workitems, so parallel modifications aren’t a concern. The others require explicit synchronization which noalias would need to be aware of. >>>>> FWIW, it seems generally useful to me to have a nomemfence function attribute and intrinsic property. We should avoid memory optimization (and possibly other optimization) across these regardless of alias analysis. >>>>> >>>> I'm think I'll try implementing this. Ideally it would be parameterized over the address space,...

...ou do is OK since it’s constant. Private address space is supposed to be totally inaccessible from other workitems, so parallel modifications aren’t a concern. The others require explicit synchronization which noalias would need to be aware of. > FWIW, it seems generally useful to me to have a nomemfence function attribute and intrinsic property. We should avoid memory optimization (and possibly other optimization) across these regardless of alias analysis. > I'm think I'll try implementing this. Ideally it would be parameterized over the address space, so it makes more sense for it to...

...o is OK since it’s constant. Private address space is supposed to be totally inaccessible from other workitems, so parallel modifications aren’t a concern. The others require explicit synchronization which noalias would need to be aware of. >> FWIW, it seems generally useful to me to have a nomemfence function attribute and intrinsic property. We should avoid memory optimization (and possibly other optimization) across these regardless of alias analysis. >> > I'm think I'll try implementing this. Ideally it would be parameterized over the address space, so it makes more sense...

On Thu, Dec 26, 2013 at 8:54 PM, Andrew Trick <atrick at apple.com> wrote: > Others can weigh in here. This is just my understanding. Attribute > propagation has to be optional because we can’t assume inter-procedural > optimization runs for correct codegen. What if the memfence resides in a > different module? > > In the case of noduplicate, the only reason to propagate AFAICT would be > to suppress inlining. It seems reasonable enough to expect attribute > propagation to happen before inlining. So I don't think noduplicate is an > issue in practice...

...ng you do is OK since it’s constant. Private address space is supposed to be totally inaccessible from other workitems, so parallel modifications aren’t a concern. The others require explicit synchronization which noalias would need to be aware of. FWIW, it seems generally useful to me to have a nomemfence function attribute and intrinsic property. We should avoid memory optimization (and possibly other optimization) across these regardless of alias analysis. -Andy

On Nov 9, 2013, at 3:14 AM, Chandler Carruth <chandlerc at google.com> wrote: > > Perhaps you're instead trying to say that with certain address spaces "noalias" (and by inference, "restrict" at the language level) has a different semantic model than other address spaces? While it's less worrisome than the first interpretation, I still don't really