similar to: __restirct ignored when including headers like <cmath>

Displaying 20 results from an estimated 300 matches similar to: "__restirct ignored when including headers like <cmath>"

2020 Jun 24
2
FW: Restrict qualifier on class members
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) {
2020 Jun 22
2
Restrict qualifier on class members
Hi Jeroen, That's great! I was trying to use the patch, what's the latest version of the project we could apply it on? Hi Neil, That seems like what I can do as well! Do you happen to have some examples lying around? Maybe a pointer to the planned presentation, if that's okay? Thank you, Bandhav On Mon, Jun 22, 2020 at 1:55 AM Neil Henning <neil.henning at unity3d.com>
2020 Jun 21
3
Restrict qualifier on class members
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
2020 Jun 22
2
Restrict qualifier on class members
Unfortunately https://llvm.org/docs/LangRef.html#llvm-loop-parallel-accesses-metadata is not a solution here. A loop-parallel access does not imply non-aliasing. The obvious case is when only reading from a location, but even when a location is written to I'd be careful to deduce that they do not alias since it might be a "benign data race" or the value never used. Additionally,
2020 May 26
2
Custom Instruction Cost Model to LLVM RISC-V Backend
Hi, I’m working on a RISC-V architecture that has instruction costs different from those in the default cost model. Is there an out-of-source way to provide llc with custom cost model? Or, does this need a change in LLVM backend? Also, the cost model is not totally static. For example, loads from 0x1000-0x1ffc take 1 cycle, whereas loads from address > 0x80000000, take 10-100 cycles. Is it
2020 May 27
2
Custom Instruction Cost Model to LLVM RISC-V Backend
Thanks a lot Henrik! I figured following would mark a pointer to a specific address space: #define __myaddrspace __attribute__((address_space(1))) __myaddrspace int* data; And, I was able to verify loads being annotated to be from addrspace 1 in the generated IR. Would this work for automatic variables as well? In regards to using this in the backend, do I have to just modify the source, or
2018 Jul 11
8
[RFC] A nofree (and nosynch) function attribute: Mixing dereferenceable and delete
Hi, everyone, I'd like to propose adding a nofree function attribute to indicate that a function does not, directly or indirectly, call a memory-deallocation function (e.g., free, C++'s operator delete). Clang/LLVM can currently misoptimize functions that:  1. Have a reference argument.  2. Free the memory backing the object to which the reference is bound during the function's
2020 Jul 11
3
Bug in pass 'ipsccp' on function attribute 'argmemonly'?
Hi all, Let's see an example (from Alexandre Isoard) first: **************************************************************************************** ; RUN: opt -ipsccp -deadargelim -licm -O2 -S < %s @g = internal global i32 0 ; Function Attrs: argmemonly define internal void @foo(i32* nonnull dereferenceable(4) %arg, i32 %val) #0 { entry: store i32 %val, i32* %arg ret void } define
2018 Jul 11
3
[RFC] A nofree (and nosynch) function attribute: Mixing dereferenceable and delete
[+Richard] On 07/11/2018 08:29 AM, Sanjoy Das wrote: > I'm not sure if nosynch is sufficient. What if we had: > > void f(int& x) { > if (false) { > int r0 = x; > } > } > > // other thread > free(<pointer to x>); > > The source program is race free, but LLVM may speculate the read from > x (seeing that it is dereferenceable) creating a
2018 Jul 12
2
[RFC] A nofree (and nosynch) function attribute: Mixing dereferenceable and delete
Thanks, Richard. Based on the feedback from this thread, I'll move forward with the patches for nofree, nosync, adding a new corresponding dereferenceable attribute (my suggestion is to name this dereferenceable_on_entry; suggestions welcome), and updating Clang is emit this new attribute instead of the current one.  -Hal On 07/11/2018 06:43 PM, Richard Smith wrote: > On Wed, 11 Jul 2018
2020 Jul 14
3
Bug in pass 'ipsccp' on function attribute 'argmemonly'?
Thank you Hal and Stefan! Bug report is filed: https://bugs.llvm.org/show_bug.cgi?id=46717 And Stefan, I think 'attributor' is a really nice pass, and can infer more precise and useful attributes, which may give more opportunities for optimization. But we shouldn't depend on 'attributor' to correct wrong function attributes, because we cannot run 'attributor' after
2017 Sep 14
2
Question about 'DAGTypeLegalizer::SplitVecOp_EXTRACT_VECTOR_ELT'
Hi All, I have a question about splitting 'EXTRACT_VECTOR_ELT' with 'v2i1'. I have a llvm IR code snippet as following: llvm IR code snippet: for.body: ; preds = %entry, %for.cond %i.022 = phi i32 [ 0, %entry ], [ %inc, %for.cond ] %0 = icmp ne <2 x i32> %vecinit1, <i32 0, i32 -23> %1 = extractelement <2 x i1>
2020 Jun 24
4
[RFC] `opt-out` attribute list for intrinsics
Hi all, A while back we started annotating intrinsics with new attributes ( https://reviews.llvm.org/D65377) After some discussion it was decided it would be good to have an `opt-out` attribute list for intrinsics. Some attributes that can be added to the list could be: nosync, nofree, nounwind, willreturn For now, there are 2 approaches: 1. Filtering opt-out attributes in tablegen source (
2017 Sep 15
2
Question about 'DAGTypeLegalizer::SplitVecOp_EXTRACT_VECTOR_ELT'
> extends the elements to 8bit and stores them on stack. Store is responsible for zero-extend. This is the policy... - Elena -----Original Message----- From: jingu at codeplay.com [mailto:jingu at codeplay.com] Sent: Friday, September 15, 2017 17:45 To: llvm-dev at lists.llvm.org; Demikhovsky, Elena <elena.demikhovsky at intel.com>; daniel_l_sanders at apple.com Subject: Re: Question
2013 Feb 25
0
[LLVMdev] loop metdata instruction
On 2/25/2013 2:08 PM, Redmond, Paul wrote: > > I've been looking through past threads looking for an answer to why the loop metadata is attached to the loop latch branch. What is the reason for putting the metadata inside the loop rather than outside (for example on the branch into the loop header.) Latch is a branch to the header. What branch in particular do you have in mind? Loop
2020 Jul 15
2
Bug in pass 'ipsccp' on function attribute 'argmemonly'?
On 7/14/20 4:34 PM, Hal Finkel via llvm-dev wrote: > > On 7/14/20 11:28 AM, Fangqing Du wrote: >> Thank you Hal and Stefan! >> >> Bug report is filed: https://bugs.llvm.org/show_bug.cgi?id=46717 >> <https://bugs.llvm.org/show_bug.cgi?id=46717> >> >> And Stefan, >> I think 'attributor' is a really nice pass, and can infer more >>
2019 Aug 08
2
Suboptimal code generated by clang+llc in quite a common scenario (?)
I found a something that I quite not understand when compiling a common piece of code using the -Os flags. I found it while testing my own backend but then I got deeper and found that at least the x86 is affected as well. This is the referred code: char pp[3]; char *scscx = pp; int tst( char i, char j, char k ) { scscx[0] = i; scscx[1] = j; scscx[2] = k; return 0; } The above gets
2020 Jul 16
2
LLVM 11 and trunk selecting 4 wide instead of 8 wide loop vectorization for AVX-enabled target
Hey list, I've recently done the first test run of bumping our Burst compiler from LLVM 10 -> 11 now that the branch has been cut, and have noticed an apparent loop vectorization codegen regression for X86 with AVX or AVX2 enabled. The following IR example is vectorized to 4 wide with LLVM 11 and trunk whereas in LLVM 10 it (correctly as per what we want) vectorized it 8 wide matching the
2004 Aug 06
6
[PATCH] Make SSE Run Time option.
So we ran the code on a Windows XP based Atholon XP system and the xmm registers work just fine so it appears that Windows 2000 and below does not support them. We agree on not supporting the non-FP version, however the run time flags need to be settable with a non FP SSE mode so that exceptions are avoided. I thus propose a set of defines like this instead of the ones in our initial patch:
2013 Feb 25
2
[LLVMdev] loop metdata instruction
Hi, I've been looking through past threads looking for an answer to why the loop metadata is attached to the loop latch branch. What is the reason for putting the metadata inside the loop rather than outside (for example on the branch into the loop header.) Note that I'm asking about llvm.loop.parallel not llvm.mem.parallel_loop_access which obviously must be inside the loop. It seems