search for: nomemf

...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 m...

...9;ve seen expressed so far seem much more appropriate for attaching to a noduplicate call to an intrinsic... But I think I'll need to read this thread again to re-absorb much of the information after the holidays. =] > > I think it would be too misleading and bizarre to define a memfence/nomemfence attribute that does not relate to memory fence instructions. In the future, I do see a potential use for such an attribute, but that discussion belongs in a different thread and would be premature (we would have to talk about alias info on calls). I’m not sure what you mean by this. I was neve...

...K 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 i...

...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. > I'm think I'll try implementing this. Ideally it would be parameterized over the address space, so it makes more sense for it...

...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 sen...

...nce 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 spa...

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

...hing 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

Hi all, I'm currently working on implementing ACLE extensions for ARM. There are some memory barrier intrinsics, i.e.__dsb and __isb that require the compiler not to reorder instructions around their corresponding built-in intrinsics(__builtin_arm_dsb, __builtin_arm_isb), including non-memory-access instructions.[1] This is currently not possible. It is sometimes useful to prevent the