search for: __restrict

Hi, I am observing a strange behaviour in which Clang ignores __restirct when I include some standard headers. For example, this code: void vec_add(int* __restrict a, int* __restrict b, int n) { #pragma unroll 4 for(int i=0; i<n; ++i) { a[i] += b[i]; } } results in: ; Function Attrs: nofree norecurse nounwind define dso_local void @_Z7vec_addPiS_i(i32* noalias nocapture %a, i32* noalias nocapture readonly %b, i32 %n) lo...

...reset. Encoding time, in seconds: GCC 32-bit: 209 ICC 32-bit: 130 VS10 32-bit: 116 VS12 32-bit: 114 GCC 64-bit: 79.5 ICC 64-bit: 81.2 VS10 64-bit: 81.1 VS12 64-bit: 83.3 According to a profiler, FLAC__lpc_compute_residual_from_qlp_coefficients_wide() is one of the most CPU consuming. I added __restrict keyword to its parameters. before it was: void FLAC__lpc_compute_residual_from_qlp_coefficients_wide(const FLAC__int32 *data, unsigned data_len, const FLAC__int32 qlp_coeff[], unsigned order, int lp_quantization, FLAC__int32 residual[]) after: void FLAC__lpc_compute_residual_from_qlp_coef...

I have a new problem: Register RBP is used in a function foo. (I am not allocating RBP to any virtual register, the instances of RBP in function foo are in the machine code when my register allocator starts.) Function foo calls function bar. Register RBP is not saved across the call, though it is live after the call. Function bar includes a virtual register. The code that I'm using to

..._)); extern int _IO_peekc_locked (_IO_FILE *__fp); extern void _IO_flockfile (_IO_FILE *) __attribute__ ((__nothrow__)); extern void _IO_funlockfile (_IO_FILE *) __attribute__ ((__nothrow__)); extern int _IO_ftrylockfile (_IO_FILE *) __attribute__ ((__nothrow__)); extern int _IO_vfscanf (_IO_FILE * __restrict, const char * __restrict, __gnuc_va_list, int *__restrict); extern int _IO_vfprintf (_IO_FILE *__restrict, const char *__restrict, __gnuc_va_list); extern __ssize_t _IO_padn (_IO_FILE *, int, __ssize_t); extern size_t _IO_sgetn (_IO_FILE *, void *, size_t); extern __off64_t _IO_seekoff (_IO_...

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

...> { > 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 ** __restrict a, float ** __restrict b) { b[2][2] = a[0][2]; b[2][2] = a[0][1]; } Ciao, Duncan. PS: Did you mean to use b[2][2] in both lines?

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

...puts a bound >> check for every array access, expecting the optimizers to remove >> redundant checks, which LLVM often does not do]. If I could teach >> LLVM that array bounds are really constant that would presumably >> solve the problem. The benefits of a const * __restrict come from two different places. The const part is essentially enforced by the front-end and the restrict part is used to inform the alias analysis (it becomes a noalias parameter attribute). The noalias parameter attribute may be of use to you eventually, but full noalias implementation isn...

Hi, I'm trying to abstract some special pointers with a class, like in the example program below: 1 #define __remote __attribute__((address_space(1))) 2 #include <stdint.h> 3 4 __remote int* A; 5 __remote int* B; 6 7 class RemotePtr { 8 private: 9 __remote int* __restrict a; 10 11 public: 12 RemotePtr(__remote int* a) : a(a) {} 13 14 __remote int& at(int n) { 15 return a[n]; 16 } 17 }; 18 19 int main(int argc, char** argv) { 20 RemotePtr a(A); 21 RemotePtr b(B); 22 23 #pragma unroll 4 24 for(int i=0; i<4; ++i) { 25...

Hi Jeroen, Sorry, I missed that. I tried the patch, and this program: #include <stdint.h> #define __remote __attribute__((address_space(1))) __remote int* A; __remote int* B; void vec_add(__remote int* __restrict a, __remote int* __restrict b, int n) { #pragma unroll 4 for(int i=0; i<n; ++i) { a[i] += b[i]; } } int main(int argc, char** argv) { __remote int* __restrict a = A; __remote int* __restrict b = B; #pragma unroll 4 for(int i=0; i<4; ++i) { a[i...

...are: llvm/projects/compiler-rt/lib/tsan/dd/dd_interceptors.cc:226:20: error: redefinition of 'realpath' INTERCEPTOR(char*, realpath, const char *path, char *resolved_path) { ^ /usr/include/bits/stdlib.h:37:8: note: previous definition is here __NTH (realpath (const char *__restrict __name, char *__restrict __resolved)) [...] libomp.so duplicate symbol __kmp_get_reduce_method in version script duplicate symbol __kmp_itt_fini_ittlib in version script duplicate symbol __kmp_itt_init_ittlib in version script LLVM ERROR: A @@ version cannot be undefined

Hi Christopher, > The benefits of a const * __restrict come from two different places. > The const part is essentially enforced by the front-end and the > restrict part is used to inform the alias analysis (it becomes a > noalias parameter attribute). The noalias parameter attribute may be > of use to you eventually, but full noalia...

...ler-rt/lib/tsan/dd/dd_interceptors.cc:226:20: > error: redefinition of 'realpath' > INTERCEPTOR(char*, realpath, const char *path, char *resolved_path) { > ^ > /usr/include/bits/stdlib.h:37:8: note: previous definition is here > __NTH (realpath (const char *__restrict __name, char *__restrict > __resolved)) > I've never seen this before. Looks like bits/stdlib.h gets pulled in only when _FORTIFY_SOURCE is enabled (which causes __USE_FORTIFY_LEVEL > 0). Do you have _FORTIFY_SOURCE set somewhere? Can you try with that not set? Teresa > > [...]...

...opher Lamb wrote: > On Aug 16, 2007, at 9:09 AM, Chris Lattner wrote: > > On Thu, 16 Aug 2007, Holger Schurig wrote: > >>> if the programmer is going to tell you that the memory pointed > >>> to by a pointer argument is never written. > > If you use a const * __restrict pointer then you should get the > benefit of this as the alias analysis will assume that the pointed to > object is neither aliased nor written. can you please explain more about what restrict means: it may help in improving code quality for Ada. In Ada you have runtime constants that a...

...d_interceptors.cc:226:20: >> error: redefinition of 'realpath' >> INTERCEPTOR(char*, realpath, const char *path, char *resolved_path) { >> ^ >> /usr/include/bits/stdlib.h:37:8: note: previous definition is here >> __NTH (realpath (const char *__restrict __name, char *__restrict __resolved)) > > > I've never seen this before. Looks like bits/stdlib.h gets pulled in only > when _FORTIFY_SOURCE is enabled (which causes > __USE_FORTIFY_LEVEL > 0). Do you have _FORTIFY_SOURCE > set somewhere? I do, it's by default a part o...

...to build CELT as a static library using VS which I would then wrap with C++/CLI so I can access the encode/decode funtionality from within C#. Is it possible to compile CELT using Visual Studio? The first issue I ran into was that VS doesn't support the 'restrict' keyword. It does have __restrict which appears to be slightly different - http://msdn.microsoft.com/en-us/library/5ft82fed(VS.80).aspx. If it's too much trouble to get it to compile with VS, are there any prebuilt .lib files availble? The celt_060_tools_win32.zip contains a libcelt-0.dll but it's out of date ( and I don...

...efine __remote __attribute__((address_space(1))) >> > 2 #include <stdint.h> >> > 3 >> > 4 __remote int* A; >> > 5 __remote int* B; >> > 6 >> > 7 class RemotePtr { >> > 8 private: >> > 9 __remote int* __restrict a; >> > 10 >> > 11 public: >> > 12 RemotePtr(__remote int* a) : a(a) {} >> > 13 >> > 14 __remote int& at(int n) { >> > 15 return a[n]; >> > 16 } >> > 17 }; >> > 18 >> > 19 int...

On Wed, 2010-06-09 at 17:30 +0200, orthochronous wrote: > Hi, > > I've been thinking about how to implement a framework for attempting > instruction scheduling of small blocks of code by using (GA/simulated > annealing/etc) controlled timing-test-evaluations of various > orderings. This sounds interesting. > (I'm particularly interested small-ish numerical inner

...> >> error: redefinition of 'realpath' > >> INTERCEPTOR(char*, realpath, const char *path, char *resolved_path) { > >> ^ > >> /usr/include/bits/stdlib.h:37:8: note: previous definition is here > >> __NTH (realpath (const char *__restrict __name, char *__restrict > __resolved)) > > > > > > I've never seen this before. Looks like bits/stdlib.h gets pulled in only > > when _FORTIFY_SOURCE is enabled (which causes > > __USE_FORTIFY_LEVEL > 0). Do you have _FORTIFY_SOURCE > > set somewhere?...

...nters (with an error), even when the compilers alias analysis determines that there is a may-alias relationship between to pointers. Take the following example, which the compiler is now free to unroll and reschedule: struct element { int a, b; }; void swap(element * arr, int size) { int * __restrict a = &arr[0].a; int * __restrict b = &arr[0].b; for (int i=0; i!=size; ++i) { int tmp = a[i]; a[i] = b[i]; b[i] = tmp; a += 2; b += 2; } } > Beyond C, some form of "based-on" relationship would also be needed > for > LLVM IR, at least so that it could cop...