similar to: 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>

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

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,

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*

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

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

Johannes, Thanks, I have been following along some of the thread(s) and the phab reviews. The scope of this work is more encompassing than our current needs and I've looked at trying to carve a piece out. It's not clear to me what purpose the llvm.noalias intrinsic serves right now. Also, if a mem instruction has !noalias metadata, then it should not be aliased, but I must be missing

> -----Original Message----- > From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Kai Peter Nacke > via llvm-dev > Sent: Tuesday, June 16, 2020 8:51 AM > To: Corentin <corentin.jabot at gmail.com> > Cc: llvm-dev at lists.llvm.org > Subject: Re: [llvm-dev] RFC: Adding support for the z/OS platform to LLVM and > clang > > > > 2) Add

Hi all, ## Status: During the past weeks I have updated the restrict patches with various improvements: - the ScopedNoAliasAA now also works together with the new pass manager - the SLPVectorizer now works nice with the noalias support. - there were some issues with some of the options enabling/disabling full restrict. These have been fixed. - various smaller enhancements. Today, I rebased the

On Thu, Jun 25, 2020 at 11:43 AM Nikita Popov via llvm-dev <llvm-dev at lists.llvm.org> wrote: > On Thu, Jun 25, 2020 at 11:22 AM Zachary Turner via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> What this means for LLVM is that everyone will have to completely stop using history rewriting operations. No more rebase, squash, amend, etc. > > This is also incorrect. Most

define dso_local i32 @f(i32 %0) { %2 = and i32 %0, 7 %3 = icmp eq i32 %2, 7 %4 = zext i1 %3 to i32 ret i32 %4 } I thought instcombine would remove it. It doesn't and nothing else does either. LLVM Version is 10.0.0. /Riyaz -------------- next part -------------- An HTML attachment was scrubbed... URL:

I'm having an issue where SROA will throw away no-alias information on some loads after inlining, because the loads are derived from a store to an alloca which can be removed after inlining. The pointers that were originally stored into the alloca do *not *have any aliasing information - the only context that allowed me to assert aliasing was that the inlined-function guaranteed it to be so.

How do I access the address qualifier from the store instruction. Given the following code: define void @test_unary_op_anegate(float %x, float addrspace(11)* %result) nounwind { entry: %neg = sub float -0.000000e+000, %x ; <float> [#uses=1] store float %neg, float addrspace(11)* %result ret void } When I attempt to generate this code, I'm

Mon Ping, Thanks for the tip, but I can't for the life of me seem to get the Value from a StoreSDNode. From looking at the SelectionDAGNodes header file, the only class that has the getValue function call is SrcValueSDNode that returns a Value type. The only class that has getType is a ConstantPoolSDNode. I don't think that ConstantPoolSDNode is what I want and when I try to cast the

The address qualifier is stored in the type of %result. From that operand, you can get the Value and then call getType. The type for result should be a PointerType which you cast to a PointerType and get the getAddressSpace e.g. cast<PointerType>(Ty)->getAddressSpace() -- Mon Ping On Sep 17, 2008, at 1:06 PM, Villmow, Micah wrote: > How do I access the address qualifier

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

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

Is copy.0 semantically equivalent to copy.1 in the following example? define void @copy.0(i8 addrspace(1)* addrspace(1)* %src, i8 addrspace(1)* addrspace(1)* %dst) { entry: %val = load i8 addrspace(1)* addrspace(1)* %src store i8 addrspace(1)* %val, i8 addrspace(1)* addrspace(1)* %dst ret void } define void @copy.1(i8 addrspace(1)* addrspace(1)* %src, i8 addrspace(1)* addrspace(1)* %dst)

> On Dec 8, 2014, at 5:12 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > > Partially answering my own question, in general these are not > equivalent because LLVM allows for pointers in different address > spaces to have different sizes. However, are they equivalent if > pointers in addrspace(1) have the same size as pointers in > addrspace(0)? > >

Hello, LLVM devs. I have the following IR: %x = alloca i32, align 4 %p = alloca i32*, align 8 store i32* %x, i32** %p, align 8 Now I change module's data layout and run InferAddressSpacePass. This turns that piece of code into %x = alloca i32, align 4, addrspace(1) %p = alloca i32*, align 8, addrspace(1) store i32 addrspace(1)* %x, i32* addrspace(1)* %p, align 8 But Verifier