search for: intrreadwriteargmem

Hi, When I define an intrinsic function with memory write permission, my assumption is that we can either attach [IntrReadWriteArgMem] or [] to the intrinsic function. Based on the comment of the source code , "IntrReadWriteArgMem - This intrinsic reads and writes only from memory that one of its arguments points to, but may access an unspecified amount." "If no property is set, the worst case is assumed (it may re...

On 03/24/2016 12:45 PM, Xiangyang Guo via llvm-dev wrote: > Hi, > > When I define an intrinsic function with memory write permission, my > assumption is that we can either attach [IntrReadWriteArgMem] or [] to > the intrinsic function. Based on the comment of the source code , > "IntrReadWriteArgMem - This intrinsic reads and writes only from > memory that one of its arguments points to, but may access an > unspecified amount." "If no property is set, the worst ca...

> On Mar 24, 2016, at 12:45 PM, Xiangyang Guo via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi, > > When I define an intrinsic function with memory write permission, my assumption is that we can either attach [IntrReadWriteArgMem] or [] to the intrinsic function. Based on the comment of the source code , "IntrReadWriteArgMem - This intrinsic reads and writes only from memory that one of its arguments points to, but may access an unspecified amount." "If no property is set, the worst case is assumed (it may re...

...ngyang 2016-03-24 14:30 GMT-07:00 Philip Reames <listmail at philipreames.com>: > > > On 03/24/2016 12:45 PM, Xiangyang Guo via llvm-dev wrote: > > Hi, > > When I define an intrinsic function with memory write permission, my > assumption is that we can either attach [IntrReadWriteArgMem] or [] to the > intrinsic function. Based on the comment of the source code , > "IntrReadWriteArgMem - This intrinsic reads and writes only from memory > that one of its arguments points to, but may access an unspecified amount." > "If no property is set, the worst case i...

sure! class TEST_INTINSIC_FM< string asmstr> : Intrinsic <llvm_i32_ty], [llvm_i32_ty, llvm_ptr_ty], [IntrReadWriteArgMem], !strconcat(“llvm.test”, asmstr),”.float”) >; tks On Jul 18, 2014, at 4:06 PM, Tom Stellard <tom at stellard.net> wrote: > On Fri, Jul 18, 2014 at 03:19:47PM -0400, kewuzhang wrote: >> en! >> >> my test is : %r1 = call<float> @test.adddiv( <float> %r0...

Hi guys, I am working on an intrinsic function, which will write to a pointer argument. So I am lowering it and think I need to catch it in lowerINTRINSIC_W_CHAIN, but somehow it always fall into INTRINSIC_WO_CHAIN category. I put [IntrReadwriteArgMem] into my Intrinsic class definition, it did not help. tried put [SDNPHasChain] into intrinsic class definition, cause errors” Element type mismatch for list”. wondering how to flag it to INTRINSIC_W_CHAIN? best Kevin

...n Jul 18, 2014, at 4:26 PM, Tom Stellard <tom at stellard.net> wrote: > On Fri, Jul 18, 2014 at 04:15:45PM -0400, kewuzhang wrote: >> sure! >> >> class TEST_INTINSIC_FM< string asmstr> : Intrinsic >> <llvm_i32_ty], [llvm_i32_ty, llvm_ptr_ty], >> [IntrReadWriteArgMem], >> !strconcat(“llvm.test”, asmstr),”.float”) >> >; > > Have a look at the SelectionDAGBuilder::visitTargetIntrinsic() > function in lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp. That is > where intrinsics are lowered to SelectionDAG nodes, so you can start >...

...r, can > we follow it? I just want to point out that the notion Igor is introducing as an attribute is not a new one. It's a prexisting notion which is already implemented within LLVM today; it's simply been restricted to intrinsics. Here's the definition from Intrinsics.td: // IntrReadWriteArgMem - This intrinsic reads and writes only from memory that // one of its arguments points to, but may access an unspecified amount. The // reads and writes may be volatile, but except for this it has no other side // effects. def IntrReadWriteArgMem : IntrinsicProperty; I did point out in the rev...

...14 2:00 PM, kewuzhang wrote: >> >> I am working on an intrinsic function, which will write to a pointer argument. >> So I am lowering it and think I need to catch it in lowerINTRINSIC_W_CHAIN, but somehow it always fall into INTRINSIC_WO_CHAIN category. >> >> I put [IntrReadwriteArgMem] into my Intrinsic class definition, it did not help. >> tried put [SDNPHasChain] into intrinsic class definition, cause errors” Element type mismatch for list”. >> >> wondering how to flag it to INTRINSIC_W_CHAIN? > > > Does it have chain in the initial DAG? >...

I am currently working on DAGToDAGISel class for MIPS and am trying to figure out a way to use INTRINSIC_W_CHAIN for an intrinsic which can return a value. My intrinsic is defined as: Intrinsic<[llvm_i32_ty],[llvm_i32_ty,llvm_i32_ty,llvm_i32_ty,llvm_i32_ty],[IntrReadWriteArgMem]>; i.e. it has four arguments and one return value In DAGToDAGISel when I try to pass it with four arguments and a return register it fails the assertion `ResNo < NumValues && "Illegal result number!"'. More specifically I am doing something like: EVT Ret...

Masked load/store are overloaded intrinsics, the only generic type is the type of the value being loaded/stored. The signature of the intrinsic is generated based on this type. The type of the pointer argument is generated as a pointer to the return type with default addrspace. E.g.: declare <8 x i32> @llvm.masked.load.v8i32(<8 x i32>*, i32, <8 x i1>, <8 x i32>) The

I'd like to clarify the meaning of "Intr*Mem" flags used in intrinsics definitions. If an intrinsic does not access memory but read and write control registers, what flag should I apply in this case: IntrNoMem or IntrReadWriteArgMem or nothing? Thanks. -- Simon

Hi, Currently in AliasAnalysis we can model ModRef behaviour for functions which only access memory through their pointer arguments. However we can't express this propery as a function attribute. For example, for intrinsics we can specify ReadWriteArgMem or ReadArgMem attributes in tablegen definitions. But due to the lack of the related function attributes on the llvm ir level, this

...rt( %p ) > > > > > > ... use %p > > br i1 %c, label %loop, label %exit > > > > > > For this reason, it has been suggested that these intrinsics are > > horribly broken, > > I disagree, these just seem like bugs. lifetime_start are marked as > IntrReadWriteArgMem, but this is not really sufficient to prevent their > removal should the memory be subsequently unused. Plus there are other > places that just delete the lifetime intrinsics, like this in > lib/Transforms/Scalar/SROA.cpp: > > // FIXME: Currently the SSAUpdater infrastructure d...

...---- Trampoline Intrinsics -----------------------===// > // > -def int_init_trampoline : Intrinsic<[llvm_ptr_ty], > +def int_init_trampoline : Intrinsic<[], > [llvm_ptr_ty, llvm_ptr_ty, llvm_ptr_ty], > - [IntrReadWriteArgMem]>, > - GCCBuiltin<"__builtin_init_trampoline">; > + [IntrReadWriteArgMem]>; > + > +def int_adjust_trampoline : Intrinsic<[llvm_ptr_ty], [llvm_ptr_ty], > + [IntrRe...

Hi! Attached set of patches splits llvm.init.trampoline into an "init" phase and an "adjust" phase, as discussed on the "Go on dragonegg" thread. Thanks! -- Sanjoy Das http://playingwithpointers.com -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Split-intrinsics-and-DAG-nodes.patch Type: text/x-diff Size: 8808 bytes Desc:

...pointer into another one and returns it. It does not read or write memory. The Intrinsic has properties: IntrNoMem. Is there any other property I can specify for the intrinsic function such as idempotent? Looking into the code, these are the properties: IntrNoMem, IntrReadArgMem, IntrReadMem, IntrReadWriteArgMem, Commutative and NoCapture. Only IntrNoMem applies to the intrinsic function. Also, what optimizations might be affected by an intrinsic function that only transforms a pointer? Is there a way to pass more information so that LLVM can do even more optimizations? Thanks a lot in advance. -Bin

> > This seems fine to me. The optimizer can (soundly) conclude that %p is > dead after the "lifetime.end" (for the two instructions), and dead before > the "lifetime.start" (for the *single* instruction in that basic block, > *not* for the previous BB). This seems like the proper result for this > example, am I missing something? > What if I put that in

Yeah. I agree that "Chain operand is needed if the intrinsic is reading / writing memory.”, Just don’t know where and how to set it up. like intrinsic “int_x86_xtest: “ def int_x86_xtest : GCCBuiltin<"__builtin_ia32_xtest">, Intrinsic<[llvm_i32_ty], [], []>; “ "def X86xtest: SDNode<"X86ISD::XTEST", SDTypeProfile<1, 0,

..... use %p > > > br i1 %c, label %loop, label %exit > > > > > > > > > For this reason, it has been suggested that these intrinsics are > > > horribly broken, > > > > I disagree, these just seem like bugs. lifetime_start are marked as > > IntrReadWriteArgMem, but this is not really sufficient to prevent > > their removal should the memory be subsequently unused. Plus there > > are other places that just delete the lifetime intrinsics, like this > > in lib/Transforms/Scalar/SROA.cpp: > > > > // FIXME: Currently the SSAUpdat...