search for: writeon

.... Instead the docs say to use the align <n> attribute. How is this supposed to work with different alignments? For example, I have one memcpy with align 4, align 4, and another with align 1, align 1. ; Function Attrs: argmemonly nounwind declare void @llvm.memcpy.p0i8.p0i8.i64(i8* nocapture writeonly align 4, i8* nocapture readonly align 4, i64, i1) #3 ; Function Attrs: argmemonly nounwind declare void @llvm.memcpy.p0i8.p0i8.i64.1(i8* nocapture writeonly align 1, i8* nocapture readonly align 1, i64, i1) #3 When I add these multiple definitions to the module, llvm mangles the name, adding `...

On 03/21/2016 08:54 AM, Nicolai Hähnle wrote: > On 19.03.2016 14:47, Philip Reames wrote: >> I'm generally in support of this change. I haven't looked at the patch >> yet, but the direction seems worthwhile. >> >> Note that we already have a writeonly predicate in a few places in the >> code (BasicAA being one). If we do introduce the new intrinsic >> property, we should refactor all of these places to use the new >> mechanism. This could be separate changes, but should be considered >> required as part of adding the...

On 19.03.2016 14:47, Philip Reames wrote: > I'm generally in support of this change. I haven't looked at the patch > yet, but the direction seems worthwhile. > > Note that we already have a writeonly predicate in a few places in the > code (BasicAA being one). If we do introduce the new intrinsic > property, we should refactor all of these places to use the new > mechanism. This could be separate changes, but should be considered > required as part of adding the new property. T...

...isn't changed, but it is changed), and will cause function return wrong constant value '1', instead of '%n' (the correct value) , like following: **************************************************************************************** ; Function Attrs: nofree norecurse nounwind writeonly define i32 @bar(i32 %n) local_unnamed_addr #0 { entry: ret i32 1 } attributes #0 = { nofree norecurse nounwind writeonly } **************************************************************************************** And if remove the 'argmemonly' attribute, function @bar will return the...

...lign <n> attribute. How is this supposed to > work with different alignments? > > For example, I have one memcpy with align 4, align 4, and another with > align 1, align 1. > > ; Function Attrs: argmemonly nounwind > declare void @llvm.memcpy.p0i8.p0i8.i64(i8* nocapture writeonly align > 4, i8* nocapture readonly align 4, i64, i1) #3 > > ; Function Attrs: argmemonly nounwind > declare void @llvm.memcpy.p0i8.p0i8.i64.1(i8* nocapture writeonly > align 1, i8* nocapture readonly align 1, i64, i1) #3 > > > When I add these multiple definitions to the...

...of size 96 bytes, by itself; the fields errors, > data_len, sense_len > and residual in a single write-only buffer; and the status field is a > separate readonly > buffer of size 1 byte, by itself." > > Here 'status field of buffer size 1 byte' is whether readonly or writeonly? Writeonly > > I want to know from which version of Qemu-kvm supports processing of > scsi commands over VirtIO block device as a backend. > Although I checked the Host Feature fields in which VIRTIO_BLK_F_SCSI > bit is set. I am using qemu-kvm version 0.12.3. Make sure you have...

...of size 96 bytes, by itself; the fields errors, > data_len, sense_len > and residual in a single write-only buffer; and the status field is a > separate readonly > buffer of size 1 byte, by itself." > > Here 'status field of buffer size 1 byte' is whether readonly or writeonly? Writeonly > > I want to know from which version of Qemu-kvm supports processing of > scsi commands over VirtIO block device as a backend. > Although I checked the Host Feature fields in which VIRTIO_BLK_F_SCSI > bit is set. I am using qemu-kvm version 0.12.3. Make sure you have...

...t > is changed), and will cause function return wrong constant value '1', > instead of '%n' (the correct value) , like following: > **************************************************************************************** > > ; Function Attrs: nofree norecurse nounwind writeonly > define i32 @bar(i32 %n) local_unnamed_addr #0 { > entry: > ret i32 1 > } > > attributes #0 = { nofree norecurse nounwind writeonly } > **************************************************************************************** > > > And if remove the 'argmemonly...

...nd, !dbg !71 ForEnd: ; preds = %ForElse, %Then call void @llvm.dbg.declare(metadata %Bar* %x, metadata !59, metadata !DIExpression()), !dbg !72 ret void, !dbg !73 } ; Function Attrs: argmemonly nounwind declare void @llvm.memset.p0i8.i64(i8* nocapture writeonly, i8, i64, i1) #3 ; Function Attrs: argmemonly nounwind declare void @llvm.memcpy.p0i8.p0i8.i64(i8* nocapture writeonly, i8* nocapture readonly, i64, i1) #3 ; Function Attrs: nobuiltin nounwind define internal fastcc void @bar2(%Bar* nonnull sret) unnamed_addr #2 !dbg !74 { Entry: call fastcc...

...ion return wrong constant value '1', instead of '%n' (the >>>     correct value) , like following: >>> **************************************************************************************** >>> >>>     ; Function Attrs: nofree norecurse nounwind writeonly >>>     define i32 @bar(i32 %n) local_unnamed_addr #0 { >>>     entry: >>>     ret i32 1 >>>     } >>> >>>     attributes #0 = { nofree norecurse nounwind writeonly } >>> ***************************************************************...

...align 8, !invariant.group !0 ;======== ret void } ; Function Attrs: alwaysinline declare void @"case_aint()_alts"() #2 ; Function Attrs: alwaysinline declare void @"case_ackerman(atom-3 atom-10)_alts"() #2 attributes #0 = { inaccessiblememonly noinline norecurse nounwind writeonly } attributes #1 = { alwaysinline norecurse nounwind } attributes #2 = { alwaysinline } !0 = distinct !{!0, !"closure_invariant_group"} ----- In my view, %closure.raw.i is a dead allocation, because the memory returned by it is not used anywhere. How do I communicate this fact to LLVM?...

...ce to promote dereferenceable_or_null - see previous nounwind - currently implemented in PruneEH, missing in new pass manager -- this one will get fixed in the near future Other cases I just noticed... noreturn -- useful for exception throw wrappers allocsize -- useful for allocation wrappers writeonly -- useful for AA speculatable - useful for speculation, LICM, PRE, etc... Untrusted Declarations In several cases, we check hasExactDefinition before checking properties of the function declaration (such as return type). To my knowledge, facts on declarations are valid even in the place of...

...(i8* align 8 %0, i8* align 8 %1, i64 8, i1 false) ; Load a copy of `var' %var.tmp = load i32*, i32** %var.addr.tmp %should.be.42 = load i32, i32* %var.tmp ret void } ; Function Attrs: argmemonly nounwind declare void @llvm.memcpy.p0i8.p0i8.i64(i8* nocapture writeonly, i8* nocapture readonly, i64, i1) #1 attributes #1 = { argmemonly nounwind } I run it with opt, and get the following: $ opt -basicaa -print-alias-sets memcpy.ll -disable-output Alias sets for function 'fun': Alias Set Tracker: 3 alias sets for 6 pointer values. Al...

...u said, fast math flags are needed for math library functions that may otherwise write errno. The full list of attributes we have so far is:    access locations: `readnone`, `inaccessiblememonly`, `argmemonly`, and `inaccessiblemem_or_argmemonly`  and access "kinds": `readonly` and `writeonly` Except for `readnone` you can combine a location attribute with a "kind" or have one of either alone. The Attributor does internally derive more "locations", basically any combination of:   local memory   constant memory   internal global memory   external global memory...

...> nounwind - currently implemented in PruneEH, missing in new pass manager -- >> this one will get fixed in the near future >> >> Other cases I just noticed... >> noreturn -- useful for exception throw wrappers >> allocsize -- useful for allocation wrappers >> writeonly -- useful for AA >> speculatable - useful for speculation, LICM, PRE, etc... >> >> >> >> Untrusted Declarations >> >> In several cases, we check hasExactDefinition before checking properties of >> the function declaration (such as return type). To...

...ereferenceable_or_null - see previous > > nounwind - currently implemented in PruneEH, missing in new pass > manager -- this one will get fixed in the near future > Other cases I just noticed... noreturn -- useful for exception throw wrappers allocsize -- useful for allocation wrappers writeonly -- useful for AA speculatable - useful for speculation, LICM, PRE, etc... > *Untrusted Declarations* > > In several cases, we check hasExactDefinition before checking > properties of the function declaration (such as return type). To my > knowledge, facts on declarations are val...

...*unexpectedly* (CSE removes the intrinsic, then InstCombine removes memset). The latter is understandable, but why the intrinsic gets optimized in the first place? - IntrArgMemOnly: none gets optimized away as expected - ReadOnly<0>: none gets optimized away as expected - ReadNone<0> / WriteOnly<0>: none gets optimized *unexpectedly* Am I missing something here or there are indeed bugs here? Btw, can you tell me how and why 'tail' changes the optimizer behavior? Thanks a lot for your explanation! Son Tuan Vu On Thu, Jul 25, 2019 at 12:57 AM Doerfert, Johannes <jdoer...

...ull - see previous > > nounwind - currently implemented in PruneEH, missing in new pass manager -- > this one will get fixed in the near future > > Other cases I just noticed... > noreturn -- useful for exception throw wrappers > allocsize -- useful for allocation wrappers > writeonly -- useful for AA > speculatable - useful for speculation, LICM, PRE, etc... > > > > Untrusted Declarations > > In several cases, we check hasExactDefinition before checking properties of > the function declaration (such as return type). To my knowledge, facts on > decl...

Hello, According to include/llvm/IR/Intrinsics.td, InstrReadMem property indicates that the intrinsic only reads from and does not write to memory. Does this mean that it can read anywhere in the memory? Because we already have 'InstrArgMemOnly' for intrinsics which only access memory that its argument(s) point(s) to. If 'InstrReadMem' really means read from anywhere in the

...cified, - its arguments and the global variable as well if Intr*Mem (other than IntrNoMem) specified. Please tell me if I'm correct or not! Thanks again, On Wed, Jul 24, 2019, 17:27 Doerfert, Johannes <jdoerfert at anl.gov> wrote: > Hi Son Tuan Vu, > > if not restricted by *writeonly*, *readonly*, or *readnone* (basically), a > call can access any object for which the > callee could potentially know the address. That means, if the address of > an object cannot be known to the callee, > it cannot access that object. An example is given below. Thus, a dead > stor...