similar to: [LLVMdev] Pointer aliasing issue

Hi, I have a question regarding pointer aliasing. I have following C code: void factorial(float **a, float **b) { b[2][2] = a[0][2]; b[2][2] = a[0][1]; } Which is converted to following LLVM IR: define void @factorial(float** nocapture %a, float** nocapture %b) nounwind { entry: %0 = getelementptr inbounds float** %b, i64 2 ; <float**> [#uses=2] %1 = load float** %0, align 8

Unfortunately since in this example function arguments are array of pointers, __restrict doesn't help. Yes, using 2 stores into same location is intentional. On Mon, Oct 11, 2010 at 12:20 PM, Duncan Sands <baldrick at free.fr> wrote: > Hi Artiom, > > > I have following C code: > > > > void factorial(float **a, float **b) > > { > >

Hi Artiom, > I have following C code: > > void factorial(float **a, float **b) > { > b[2][2] = a[0][2]; > b[2][2] = a[0][1]; > } ... > Assuming that a and b arrays contains pointers that are not aliased, > is it possible to remove the first store by using some C or LLVM IR specific > declarations? try this: void factorial(float **

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

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

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?

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;

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

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.

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.

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

Hi, I'm working on OpenCL and I'm using clang as compiler (based on clang 3.7.0). I have a issue, I'm generating a bitcode file (that I can print before before the generation). But when I'm trying to read it again with clang, I have this issue: "error: Invalid record" How can I managed to know where it comes from? Thank you, Romaric Here is what is print before the

I was looking at the code generated from the following c code and noticed extra loads in the inner-loop of these nested for-loops: #define DIM 8 #define UNROLL_DIM DIM typedef double InArray[DIM][DIM]; void f1( InArray c, InArray a, InArray b ) { #pragma clang loop unroll_count(UNROLL_DIM) for( int i=0;i<DIM;i++) #pragma clang loop unroll_count(UNROLL_DIM) for( int

Hi, I have the following IR code </snippet> %prev = getelementptr inbounds %struct.myStruct* %node, i32 0, i32 1 %1 = load %struct.myStruct** %prev, align 4, !tbaa !0 %next1 = getelementptr inbounds %struct.myStruct* %1, i32 0, i32 0 store %struct.myStruct* %0, %struct.myStruct** %next1, align 4, !tbaa !0 %2 = load %struct.myStruct** %prev, align 4, !tbaa ! </snippet> myStruct is

On Thu, Oct 25, 2012 at 3:15 PM, Pranav Bhandarkar <pranavb at codeaurora.org>wrote: > Hi, > > I have the following IR code > > </snippet> > %prev = getelementptr inbounds %struct.myStruct* %node, i32 0, i32 1 > %1 = load %struct.myStruct** %prev, align 4, !tbaa !0 > %next1 = getelementptr inbounds %struct.myStruct* %1, i32 0, i32 0 > store %struct.myStruct*

Hello, I was wondering if we had a way to strength reduce getelementptr today. For the following code: void func(float (&A)[132][140]) { > for (int i = 0; i < 132; ++i) > for (int j = 0; j < 140; ++j) > A[i][j] += 1; > } We will generate: (annotated with SCEV) define void @func([132 x [140 x float]]* nocapture dereferenceable(73920)) local_unnamed_addr #0 {

On Thu, Dec 8, 2011 at 4:26 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Thu, Dec 8, 2011 at 2:11 PM, Vitor Luis Menezes <vitor at utexas.edu> wrote: >> We've got the following test case: >> >> >> class A { >> public: >>   int x; >>   A(int x) : x(x) {} >>   int hoo() {return 4;} >>   virtual int foo() {return x;}

Hi, I've been stuck with this problem for a while now, and my supervisor's starting to think it's a bug in lli, but I thought I'd ask here before going down that route. I have this code, which stores an array in my 'MainClass', and prints out an element of it. Note that the print statement is irrelevant here, it segfaults regardless, and this code has been run with -O2

Hello Micah, I first apologize for the mail length, but I think that using an example would be better to clarify the case and the objections. > [Micah Villmow] In the case of OpenCL, you can't correctly use the standard C calling convention and still be OpenCL compliant, the C calling convention is too permissive. The second you use OpenCL, you are using an OpenCL specific calling

Hi Andrew, The issue below refers to LSR, so I'll appreciate your feedback. It also refers to instruction combining and might impact backends other than X86, so if you know of others that might be interested you are more than welcome to add them. Thanks, Anat _____________________________________________ From: Shemer, Anat Sent: Tuesday, February 18, 2014 15:07 To: 'llvmdev at