similar to: [LLVMdev] Add a new llvm intrinsic?

Chandler pointed out another interpretation of C11/6.7.3.1, in which 'restrict' only addresses aliasing within a single thread. If that's the right interpretation, then it's a bug in LLVM that it moves noalias pointers across memory-ordering operations at all, and you still don't need a new fence, just a bug fix. 6.7.3.1 says "During each execution of B, ...".

This sounds a lot like the question at http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-July/064462.html. It sounds like you have a pointer marked 'restrict', but it's actually aliased in another thread. That would be undefined behavior even with a stronger fence. On Tue, Aug 6, 2013 at 4:56 PM, Guo, Xiaoyi <Xiaoyi.Guo at amd.com> wrote: > Hi, > > In OpenCL, the

Hi Jeff, Do you know if anything came of this? I understand we may need to seek clarification to get a formal answer, particularly with respect to C, but it seems pretty clear to me that this is a significant QoI issue, both for C and CL. LLVM is effectively hoisting a load above a thread-join. This may or may not technically allowed in C, but it seems generally undesirable, and it’s extremely

Sorry for the delay in getting back to you. I don't know if anything came out of this, since Xiaoyi never wrote back. What does some of the affected code look like? My opinion is still that 'restrict' should mean that no other thread should use a pointer aliasing the restrict pointer, although if many threads are started after the lifetime of the restrict pointer starts, and they

Hi Jeff, It’s not really meaningful to talk about threads being created in the context of an OpenCL kernel. The other threads are always present. void kernel(int * restrict array, int * restrict array2) { int value = array[0] + get_thread_id() + 1; barrier(); array[get_thread_id()] = value; barrier(); array2[get_thread_id()] = array[0]; } In this example code, the kernel is well

On Wed, Jun 12, 2013 at 7:28 PM, Guo, Xiaoyi <Xiaoyi.Guo at amd.com> wrote: > So fence only forces ordering of atomic instructions.**** > > ** ** > > Let me change my question then.**** > > ** ** > > If I have a target-specific intrinsic which forces ordering of ordinary > load/store instructions. Then should it also force ordering of load/stores > to

On Thu, Jun 13, 2013 at 10:52 AM, Guo, Xiaoyi <Xiaoyi.Guo at amd.com> wrote: > I mean something like a target-specific fence machine instruction which > forces ordering of all loads/stores. I want to clarify the meaning of > “noalias” in this case. Is the fence machine instruction considered > “touching” all memory and thus breaks the “noalias” contract? > A fence

On Wed, Jun 12, 2013 at 6:17 PM, Guo, Xiaoyi <Xiaoyi.Guo at amd.com> wrote: > Hi, > > I have the following test case: > > define void @foo(<2 x float>* noalias nocapture %out, <2 x float>* > noalias nocapture %data0) nounwind { > entry: > %val1 = load <2 x float>* %data0, align 8 > store <2 x float> %val1, <2 x float>* %out,

On Thu, Jun 13, 2013 at 11:39 AM, Guo, Xiaoyi <Xiaoyi.Guo at amd.com> wrote: > In a multi-threaded environment, in order to ensure the memory ordering > expressed by the memory fence, certain memory operations should not be > moved across the fence, right?**** > > ** > Yes, but operations on noalias pointers don't fall into that category. For noalias pointers, while

I mean something like a target-specific fence machine instruction which forces ordering of all loads/stores. I want to clarify the meaning of "noalias" in this case. Is the fence machine instruction considered "touching" all memory and thus breaks the "noalias" contract? Xiaoyi From: Eli Friedman [mailto:eli.friedman at gmail.com] Sent: Wednesday, June 12, 2013 8:08

In a multi-threaded environment, in order to ensure the memory ordering expressed by the memory fence, certain memory operations should not be moved across the fence, right? From: Eli Friedman [mailto:eli.friedman at gmail.com] Sent: Thursday, June 13, 2013 11:18 AM To: Guo, Xiaoyi Cc: LLVM Dev Subject: Re: [LLVMdev] A question w.r.t fence instruction vs. noalias pointer On Thu, Jun 13, 2013 at

So fence only forces ordering of atomic instructions. Let me change my question then. If I have a target-specific intrinsic which forces ordering of ordinary load/store instructions. Then should it also force ordering of load/stores to noalias pointers in caller functions? Thanks, Xiaoyi From: Eli Friedman [mailto:eli.friedman at gmail.com] Sent: Wednesday, June 12, 2013 7:06 PM To: Guo,

On 7 June 2013 17:52, Dallman, John <john.dallman at siemens.com> wrote: > Is it possible for the debug information to mark all the instructions that arise > from a > language statement as coming from that statement, even though the instructions may > be widely scattered? Yes. > Instructions whose effects > are used in the logic from more than one statement would have to

Hi, I have the following test case: define void @foo(<2 x float>* noalias nocapture %out, <2 x float>* noalias nocapture %data0) nounwind { entry: %val1 = load <2 x float>* %data0, align 8 store <2 x float> %val1, <2 x float>* %out, align 8 fence acq_rel %val2 = load <2 x float>* %data0, align 8 store <2 x float> %val2, <2 x float>*

Hi, It seems orderings are not assigned to DAG nodes created after the DAG builder, e.g., DAG nodes created during legalization. This causes instructions being scheduled in different order than source order for O0. This is my plan to fix it: Make a utility routine that recursively assign ordering to a chain of nodes, just like what SelectionDAGBuilder::AssignOrderingToNode() does. Then add call

On Mon, Jul 29, 2013 at 4:08 PM, Guo, Xiaoyi <Xiaoyi.Guo at amd.com> wrote: > Hi,**** > > ** ** > > We have a benchmark where there are 128 MAD computations in a loop. (See > the attached IR.) Creating SCEVs for these expressions takes a long time, > making the compile time too long. E.g., running opt with the “indvars” pass > only takes 45 seconds.**** > >

On Jul 29, 2013, at 4:08 PM, Guo, Xiaoyi <Xiaoyi.Guo at amd.com> wrote: > Hi, > > We have a benchmark where there are 128 MAD computations in a loop. (See the attached IR.) Creating SCEVs for these expressions takes a long time, making the compile time too long. E.g., running opt with the “indvars” pass only takes 45 seconds. > > It seems that the majority of the time is

Hi Xiaoyi, Do you still see this behavior after r177525? I recently fixed several places where ordering was not propagated, including during legalization. There are probably still cases that are missed, but I'd be interested in seeing a missed case. I'm guessing it's a legalization that expands to multiple new nodes. The AssignOrdering calls in the legalizer may need to be expanded

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

Hi Eric, Sorry I wasn't clear. The problem happened in the "source" pre-RA scheduler, which relies on DAG node ordering to schedule the nodes. Xiaoyi From: Eric Christopher [mailto:echristo at gmail.com] Sent: Tuesday, April 30, 2013 12:54 AM To: Guo, Xiaoyi Cc: LLVM Developers Mailing List Subject: Re: [LLVMdev] [PATCH] Propagate DAG node ordering during legalization and