similar to: [LLVMdev] address space in llvm

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

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

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

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

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 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 08/07/2013 01:52 PM, Michele Scandale wrote: > > IMHO this information should be a plus that could be *safely* ignored > when not necessary and used where it can provide an improvement in > optimizations. This does not necessary mean the the middle-end (and > the back-ends) must be aware of the semantic of these logical address > spaces, it would be enough just to

On 2 Sep 2015, at 02:54, Joseph Tremoulet via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Reading further, I see both that addrspacecast "can be a no-op cast or a complex value modification"[2] and that bitcast "may only be [used on pointers] with the same address space"[4]. > > So I'm getting the impression that it's ok to have a model with

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

On Aug 7, 2015, at 8:28 PM, Hal Finkel <hfinkel at anl.gov<mailto:hfinkel at anl.gov>> wrote: ________________________________ From: "Jingyue Wu" <jingyue at google.com<mailto:jingyue at google.com>> To: "Matt Arsenault" <Matthew.Arsenault at amd.com<mailto:Matthew.Arsenault at amd.com>> Cc: llvm-dev at lists.llvm.org<mailto:llvm-dev at

Thank you very much for your reply. Do you mean calculate the hash based on element SCEV pointers? But according to the 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

On Fri, Aug 7, 2015 at 12:01 PM, Matt Arsenault <Matthew.Arsenault at amd.com> wrote: > On 08/07/2015 11:35 AM, Jingyue Wu wrote: > > + the new llvm-dev > > On Fri, Aug 7, 2015 at 11:30 AM, Jingyue Wu <jingyue at google.com> wrote: > >> Hi folks, >> >> Unsurprisingly, leveraging the fact that certain address spaces don't >> alias can

On Aug 7, 2013, at 2:07 PM, Matt Arsenault <Matthew.Arsenault at amd.com> wrote: > On 08/07/2013 01:52 PM, Michele Scandale wrote: >> >> IMHO this information should be a plus that could be *safely* ignored when not necessary and used where it can provide an improvement in optimizations. This does not necessary mean the the middle-end (and the back-ends) must be aware of the

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

On 1/8/2015 1:55 AM, Philip Reames wrote: >>>> I think the problems aren’t so much that accessing 0 doesn’t work >>>> (although I imagine there are problems with that), but expectations >>>> of comparison with null. The main problem I’m aware of is >>>> comparisons with null pointers. The first global object in >>>> addrspace(3) will

On Thu, Aug 8, 2013 at 12:51 PM, Pete Cooper <peter_cooper at apple.com> wrote: > > > Sent from my iPhone > > > On Aug 8, 2013, at 5:39 AM, Michele Scandale <michele.scandale at gmail.com> > wrote: > > > >> On 08/08/2013 02:16 PM, Justin Holewinski wrote: > >> Why should SelectionDAGBuilder generate an explicit bitcast for a no-op >

Hi Matthijs, Sorry for not responding earlier. I have a few comments. On Aug 7, 2008, at 7:41 AM, Matthijs Kooijman wrote: > Hi Mon Ping, > > I've again attached a patch, wich lets LLVM know about about the > relations > between different address spaces. Instead of cramming this info in > with > TargetData (with all kinds of unwanted side effects, especially for

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