search for: __restrict__

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

Hello, I've been playing around with the really simple example of not cache friendly loop like this: #define N 100 void foo(int** __restrict__ a, int** __restrict__ b) { for (int i = 0; i < N; ++i) for (int j = 0; j < N; ++j) a[j][i] += b[j][i]; } link to compiler explorer: https://gcc.godbolt.org/#g:!((g:!((g:!((h:codeEditor,i:(j:1,source:'%23define+N+100%0A%0Avoid+foo(int**+__restrict__+a,+%0A...

...me 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? 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, >...

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; *y = *x + 2; *z = *x + 3; return *x + *y + *z; } everything works as expected: define double @_Z1fPdS_S_(doubl...

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

...red). Cheers, Roel On 01/24/2012 03:59 PM, Brent Walker wrote: > 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; > *y = *x + 2; > *z = *x + 3; > > return *x + *y + *z; > } > &...

...fadd double %6, %3 > ret double %7 > } > > !0 = metadata !{metadata !"double", metadata !1} > !1 = metadata !{metadata !"omnipotent char", metadata !2} > !2 = metadata !{metadata !"Simple C/C++ TBAA", null} > > (I used arguments here without __restrict__ which has the same effect as > loading my pointers from context as locals). As you can see we keep > loading the value of x from memory, even though we just stored a local > into it. Given that I am generating LLVM IR directly (via the C++ > interface) can you suggest someway I could...

.... >> >> 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? 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 Duncan, you have misunderstood me I think. Of course in this case you have to reload the doubles since as you say the pointers may be aliasing each other. I just wrote it this way to show the kind of code one gets if one cannot specify that pointers do now alias -- not adding the __restrict__ to the function arguments gives the same code as in my example with the local variables (with or without the restrict). If you could you answer the question in my email I would be grateful. Given that I am generating IR directly, is it possible for me to mark locals pointers as non-aliasing? When...

...baa !0 %6 = fadd double %4, %5 %7 = fadd double %6, %3 ret double %7 } !0 = metadata !{metadata !"double", metadata !1} !1 = metadata !{metadata !"omnipotent char", metadata !2} !2 = metadata !{metadata !"Simple C/C++ TBAA", null} (I used arguments here without __restrict__ which has the same effect as loading my pointers from context as locals). As you can see we keep loading the value of x from memory, even though we just stored a local into it. Given that I am generating LLVM IR directly (via the C++ interface) can you suggest someway I could pass the noalias att...

...t compile time. define double @f(double** nocapture %p) nounwind uwtable readnone { ret double 8.000000e+00 } Now consider the function below. I know (in my particluar case) that the pointers in the p array do not alias each other. I tried to communicate this information to llvm/clang via the __restrict__ qualifier but it does not seem to have an effect. Can you please suggest what is wrong. How can I achieve what I want? double f(double** p ) { double *__restrict__ x = p[0]; double *__restrict__ y = p[1]; double *__restrict__ z = p[2]; *x = 1; *y = *x + 2; *z = *x + 3; ret...

On Jan 24, 2012, at 7:45 AM, 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? There are stores here as well. LLVM ignores restrict everywhere except function parameters. This is a compromise aimed at a sweet spot in the balance of compiler complexity vs. optimization opportunity....

...@f(double** nocapture %p) nounwind uwtable readnone { > ret double 8.000000e+00 > } > > Now consider the function below. I know (in my particluar case) that > the pointers in the p array do not alias each other. I tried to > communicate this information to llvm/clang via the __restrict__ > qualifier but it does not seem to have an effect. Can you please > suggest what is wrong. How can I achieve what I want? > > double f(double** p ) > { > double *__restrict__ x = p[0]; > double *__restrict__ y = p[1]; > double *__restrict__ z = p[2]; > >...

...printf(char *buffer, size_t max, const char *format, ...) >>>? ? ???^ >>> In file included from compat.c:3:0: >>> F:/MinGW64/x86_64-w64-mingw32/include/stdio.h:553:5: note: previous >>> definition of 'snprintf' was here >>>???int snprintf (char * __restrict__ __stream, size_t __n, const char * >>> __restrict__ __format, ...) >>>? ? ???^ >>> compat.c:75:5: error: redefinition of 'vsnprintf' >>>???int vsnprintf(char *buffer, size_t bufferSize, const char *format, >>> va_list args) >>>? ? ???^ &...

Hi, LLVM community: I found basicaa seems not to tell must-not-alias for __restrict__ arguments in c/c++. It only compares two pointers and the underlying objects they point to. I wonder how clang does alias analysis for c/c++ keyword restrict. let assume we compile the following code: $cat myalias.cc float foo(float * __restrict__ v0, float * __restrict__ v1, float * __restrict_...

...1 = 4 index_0 = 1 index_1 = 5 index_0 = 2 index_1 = 6 index_0 = 3 index_1 = 7 loop iter 1: index_0 = 8 index_1 = 12 index_0 = 9 index_1 = 13 index_0 = 10 index_1 = 14 index_0 = 11 index_1 = 15 For completeness, here the code: void bar(std::uint64_t start, std::uint64_t end, float * __restrict__ c, float * __restrict__ a, float * __restrict__ b) { const std::uint64_t inner = 4; for (std::uint64_t i = start ; i < end ; i+=4 ) { { const std::uint64_t ir0 = ( ((i+0)/inner) * 2 + 0 ) * inner + (i+0)%4; const std::uint64_t ir1 = ( ((i+0)/inner) * 2 + 1 ) * inner +...

...er detects 8 stores, but it can’t prove that they are consecutive, so it moves on. Can you simplify the address expression ? Can you write " index0 = i*8 + 0 “ and give it a try ? > > For completeness, here the code: > > void bar(std::uint64_t start, std::uint64_t end, float * __restrict__ c, float * __restrict__ a, float * __restrict__ b) > { > const std::uint64_t inner = 4; > for (std::uint64_t i = start ; i < end ; i+=4 ) { > { > const std::uint64_t ir0 = ( ((i+0)/inner) * 2 + 0 ) * inner + (i+0)%4; > const std::uint64_t ir1 = ( ((i+0)/inner) *...

..., at 8:01 AM, Frank Winter <fwinter at jlab.org> wrote: > A quite small but yet complete example function which all vectorization passes fail to optimize: > > #include <cstdint> > #include <iostream> > > void bar(std::uint64_t start, std::uint64_t end, float * __restrict__ c, float * __restrict__ a, float * __restrict__ b) > { > for ( std::uint64_t i = start ; i < end ; i += 4 ) { > { > const std::uint64_t ir0 = (i+0)%4 + 8*((i+0)/4); > c[ ir0 ] = a[ ir0 ] + b[ ir0 ]; > } > { > const std::uin...

A quite small but yet complete example function which all vectorization passes fail to optimize: #include <cstdint> #include <iostream> void bar(std::uint64_t start, std::uint64_t end, float * __restrict__ c, float * __restrict__ a, float * __restrict__ b) { for ( std::uint64_t i = start ; i < end ; i += 4 ) { { const std::uint64_t ir0 = (i+0)%4 + 8*((i+0)/4); c[ ir0 ] = a[ ir0 ] + b[ ir0 ]; } { const std::uint64_t ir0 = (i+1)%4 + 8*((i+1)/4...

...ull will give you a command line for opt, equivalent to -O2, with the passes named explicitly. This is helpful for investigating these kinds of questions. -Hal ----- Original Message ----- > > > Hi, LLVM community: > > > I found basicaa seems not to tell must-not-alias for __restrict__ > arguments in c/c++. It only compares two pointers and the underlying > objects they point to. I wonder how clang does alias analysis > for c/c++ keyword restrict. > > > let assume we compile the following code: > $cat myalias.cc > > float foo(float * __restrict__ v0,...