similar to: [LLVMdev] GVN incorrectly handling readnone parameter attribute?

On 05/21/2014 02:52 PM, Robert Lougher wrote: > On 21 May 2014 21:40, Robert Lougher <rob.lougher at gmail.com> wrote: >> define i32* @get_pntr(i32* readnone %p) { >> entry: >> ret i32* %p >> } >> >> define void @store(i32* nocapture readnone %p) { >> entry: >> store i32 10, i32* %p, align 4, !tbaa !1 >> ret void >> }

Confirmed, this is a bug. This define i32* @get_pntr(i32* %p) nounwind uwtable { entry: ret i32* %p } define void @store(i32* %p) noinline nounwind uwtable { entry: %call = call i32* @get_pntr(i32* %p) store i32 10, i32* %call, align 4 ret void } run through opt -functionattrs gets a 'readnone' on @store's %p. That's wrong, it clearly stores to it. The bug is due to

On 23 May 2014 09:42, Robert Lougher <rob.lougher at gmail.com> wrote: > Hi Nick, > > Thanks for replying. Bug filed: > http://llvm.org/bugs/show_bug.cgi?id=19842 Thank you! Strangely enough, my first conclusion was that %p was being marked > readnone incorrectly as it wasn't handling the copy via @get_addr. > Sorry -- saying %p alone is ambiguous because

Hi all, I'm currently building a DSL for a computer graphics project that is not unlike NVIDIA's Cg. I have an intrinsic with the following signature float4 sample(texture tex, float2 coords); that is translated to this LLVM IR code: declare void @"sample"(%float4* noalias nocapture sret, %texture, $float2) nounwind readnone The type float4 is basically an array of four

Hi, On 08/07/2015 10:30 PM, Nick Lewycky wrote: [...] > Depends. What is the exact declaration of format_long? > > > In the input .ll file it is: > > ; Function Attrs: minsize optsize > define internal i16 @format_long(i16* %res.8.par, i16 %base.9.par, > i32 %x.10.par) #3 { > > which is later changed somewhere in opt to: > > ;

Hi LLVMers, I would like to ask a question regarding aliasing. Suppose I have the following program: double f(double** p ) { double a,b,c; double * x = &a; double * y = &b; double * z = &c; *x = 1; *y = *x + 2; *z = *x + 3; return *x+*y+*z; } LLVM can tell that the three pointers do not alias each other so can perform the constant folding at compile time.

Hello all, There is a missing vectorization opportunity issue with clang 4.0 with the file attached. Indeed, when compiled with -O2, the "op_distance" function get vectorized, but not the "op" one. For information, this test case has been reduced from a file generated by the Pythran compiler (https://github.com/serge-sans-paille/pythran). If we take a look at the generated

Hi Dan and Others , I'm newbie to LLVM and Clang ,But has experience on compiler optimization and VM . Everyone talking about the LLVM in my organisation so thought of peeking into it and where this discussion is stalled me ... so i tried to simulate the problem ,which is discussed here . vi sample.c double f(double** p ) { double a,b,c; double * x = &a; double * y =

Hi Brent, Looking at your code I can see at least one reason why some of the store operations remain in the output since you are (through x, y, and z) writing in memory which exists outside of your function (p). Constant propagation also seems to work in the first few lines, *y = *x +1 (%3) is stored directly. The strange thing to me is that the same doesn't happen for *z = *x + 2. Here

How do I tell the optimizer that the (dereferenced) value of an i8** parameter is NULL at the start so that it can eliminate the check? I have code like: void test2(void** ex) { printf("go\n"); // does not change *ex } void call2(void** ex); void testeh(void** ex) { // I want to tell the optimizer *ex is null so it can eliminate the first

Hi Roel, the code you list below is precisely what I expect to get (of course the stores must happen but the constant folding should happen as well). It all looks very strange. LLVM is behaving as if the __restrict__ keyword was not used at all. Even more strange is the fact that for this function: double f(double *__restrict__ x, double *__restrict__ y, double *__restrict__ z) { *x = 1.0;

Can you send the IR you are using? Volkan On Thu, Oct 8, 2015 at 6:28 AM Erdem Derebaşoğlu < erdemderebasoglu at hotmail.com> wrote: > Thanks. I enabled my pass. I have one resolved issue though: > MachineMemOperand::getAddrSpace() always returns zero. How can I use it to > distinguish private memory accesses? > > Erdem > > ------------------------------ > From:

I think the problem here is that the IR doesn't have any way to attach restrict information to loads/stores/pointers. It works on arguments because they can be given the 'noalias' attribute, and then the alias analyzer must understand what that means. Pete On Jan 24, 2012, at 7:47 AM, Roel Jordans wrote: > I have no clue, I didn't have time to look into that example yet.

Hi Brent, I think this is a problem in the easy-cse transform. In this transform load operations can be replaced by their subexpression, in this case the propagated constant, based on the value of the 'CurrentGeneration' of memory writes. This implies that any store operation invalidates the knowledge about previously stored subexpressions. In general, this is a safe assumption but

On 8 Aug 2013, at 04:23, Pete Cooper <peter_cooper at apple.com> wrote: > > On Aug 7, 2013, at 7:23 PM, Michele Scandale <michele.scandale at gmail.com> wrote: > >> On 08/08/2013 03:52 AM, Pete Cooper wrote: >> >> From here I understand that in the IR there are addrspace(N) where N=0,1,2,3,... according to the target independent mapping done by the

Can you explain please why it works for this version of the function: double f(double *__restrict__ x, double *__restrict__ y, double *__restrict__ z); What is different here? There are stores here as well. Brent On Wed, Jan 25, 2012 at 12:34 AM, Roel Jordans <r.jordans at tue.nl> wrote: > Hi Brent, > > I think this is a problem in the easy-cse transform. In this transform

I have no clue, I didn't have time to look into that example yet. How does the IR (before optimization) differ from the other version? Roel On 01/24/2012 04:45 PM, Brent Walker wrote: > Can you explain please why it works for this version of the function: > > double f(double *__restrict__ x, double *__restrict__ y, double > *__restrict__ z); > > What is different here?

On 5 Okt., 23:33, Dan Gohman <goh... at apple.com> wrote: > > Is there a reason it needs to be an array? A vector of four floats > wouldn't have this problem, if that's an option. > Unfortunately that's not an option. At the moment I'm restricting myself to the use of scalar code only, in order to be able to vectorize the code easily later (e.g., float4 as it is

Peter Cooper wrote: > I think the problem here is that the IR doesn't have any way to attach restrict information to loads/stores/pointers. I think we do now, actually. Now that the loads and stores have TBAA metadata, I think the restrict attribute can go there. It needs to be attached to every use of a restrict pointer, but that's similar to how TBAA already works. > It works

LLVM today does not clearly specify if a function specified to not write to memory (i.e. readonly or readnone) is allowed to throw exceptions. LangRef is ambiguous on this issue. The normative statement is "[readnone/readonly functions] cannot unwind exceptions by calling the C++ exception throwing methods" which does not decide an answer for non C++ languages. It used to say (h/t