similar to: [LLVMdev] [PATCH] Propagate DAG node ordering during legalization and instruction selection

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

On Tue, Apr 30, 2013 at 12:48 AM, Guo, Xiaoyi <Xiaoyi.Guo at amd.com> wrote: > Hi,**** > > ** ** > > We’ve recently encountered a problem in our compiler where the line number > in debug info jumps back and force even at O0. This is caused by DAG node > ordering not being properly kept during legalization and instruction > selection. There are still uncaught cases

On Apr 30, 2013, at 11:00 AM, "Guo, Xiaoyi" <Xiaoyi.Guo at amd.com> wrote: > 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. In your case, Eric's suggestion was effectively "start implementing fast-isel". Which is not a bad idea if you want to reduce compile

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

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

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

Hi Andy, Thanks very much for looking into the problem. In this particular test case, it seems most of the time is spent in the sorting, not the grouping. Later, I realized that it seems in this test case most of the expressions to be compared have different length. I tried the following change in compare() when the LHS and RHS's types are the same:

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,

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

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, ...".

Hi, In OpenCL, the "barrier()" function, as well as various target specific memory fence intrinsics, should prevent loads/stores of the relevant address space from being moved across them. Kernel pointers with "restrict" attributes are implemented by marking the pointer "noalias" in the LLVMIR. However, in LLVM, "noalias" pointers are not affected by llvm

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

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

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

On Thu, Dec 8, 2011 at 11:36 AM, Villmow, Micah <Micah.Villmow at amd.com>wrote: > It is my understanding that all you need to do is specify let isTarget = > 1 in your .td file and it will generate target specific intrinsics. This > should allow you to keep the IntrinsicsPTX.td file in the same location. > So we keep the intrinsics defined in include/llvm/IntrinsicsPTX.td?