search for: xiaoyi

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

...fer the original node's order to newly created node. If that routine creates a chain of nodes, then I only need to call the utility routine for the last of the chain. There will be a lot of places to change. So I want to get agreement on the fix before I go ahead and make the changes. Thanks, Xiaoyi -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130327/67fe172d/attachment.html>

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

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

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

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

...comments before GroupByComplexity(): /// Note that we go take special precautions to ensure that we get deterministic /// results from this routine. In other words, we don't want the results of /// this to depend on where the addresses of various SCEV objects happened to /// land in memory. Xiaoyi From: Daniel Berlin [mailto:dberlin at dberlin.org] Sent: Monday, July 29, 2013 4:18 PM To: Guo, Xiaoyi Cc: LLVMdev at cs.uiuc.edu Subject: Re: [LLVMdev] creating SCEV taking too long On Mon, Jul 29, 2013 at 4:08 PM, Guo, Xiaoyi <Xiaoyi.Guo at amd.com<mailto:Xiaoyi.Guo at amd.com>>...

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

...ean 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 PM To: Guo, Xiaoyi Cc: LLVM Dev Subject: Re: [LLVMdev] A question w.r.t fence instruction vs. noalias pointer On Wed, Jun 12, 2013 at 7:28 PM, Guo, Xiaoyi <Xiaoyi.Guo at amd.com<mailto:Xiaoyi.Guo at am...

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

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, Xiaoyi Cc: LLVM Dev Subject: Re: [LLVMdev] A question w.r.t fence instruction vs. noalias pointer On Wed, Jun 12, 2013 at 6:17 PM, Guo, Xiaoyi <Xiaoyi.Guo at amd.com<mailto:Xiaoyi.Guo at a...

...blem for cases when most of the time the expressions to be compared have different lengths. However, the problem still exists if the expressions to be compared are large, similar, and have the same length. Maybe I'll leave that to later when there's a test case for such situations? Thanks, Xiaoyi From: Andrew Trick [mailto:atrick at apple.com] Sent: Tuesday, July 30, 2013 2:20 PM To: Guo, Xiaoyi Cc: LLVMdev at cs.uiuc.edu; Dan Gohman Subject: Re: [LLVMdev] creating SCEV taking too long On Jul 29, 2013, at 4:08 PM, Guo, Xiaoyi <Xiaoyi.Guo at amd.com<mailto:Xiaoyi.Guo at amd.com>&...

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 instruction selection On Tue, Apr 30, 2013 at 12:48 AM, Guo, Xiaoyi &l...

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 10:52 AM, Guo, Xiaoyi <Xiaoyi.Guo at amd.com<mailto:Xiaoyi.Guo at amd.com>> wrote: I mean something like a target-specific fence machine instruction which forces ordering...

Hi Xiaoyi, this looks like a bug to me - please file a bug report. Ciao, Duncan. On 01/11/12 04:35, Guo, Xiaoyi wrote: > I have three modules: > ----------------------------------------------------------------- > s1.ll: > > %0 = type <{ i32, i32 }> > > define void @s1(%0* byval %...

...l void @s2(%0* %myStruct) nounwind ret void } define void @s1(%0* byval %myStruct) nounwind { return: ret void } define void @s2(%0* byval %myStruct) nounwind { return: ret void } Shouldn't the second linked IR be generated regardless of the order the modules are linked in? Thanks, Xiaoyi

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

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

...ns to get the full effect), and which prevents even noalias pointers from being moved across it? Alternatively (possibly nicer) would be something that looks like the memset intrinsic, which can work for any address space. llvm.addrspace_fence.p1.p2(void) llvm.addrspace_fence.p1(void) ... Thanks, Xiaoyi

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