search for: memfenc

Displaying 9 results from an estimated 9 matches for "memfenc".

Did you mean: memfence
2013 Dec 05
3
[LLVMdev] Loads moving across barriers
...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...
2013 Dec 05
0
[LLVMdev] Loads moving across barriers
...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...
2014 Jan 04
2
[LLVMdev] Loads moving across barriers
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...
2013 Dec 21
2
[LLVMdev] Loads moving across barriers
...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,...
2013 Dec 04
2
[LLVMdev] Loads moving across barriers
...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...
2013 Dec 05
0
[LLVMdev] Loads moving across barriers
...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...
2013 Dec 27
3
[LLVMdev] Loads moving across barriers
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...
2013 Nov 11
0
[LLVMdev] Loads moving across barriers
...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
2013 Nov 09
3
[LLVMdev] Loads moving across barriers
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