similar to: [LLVMdev] Write-only intrinsics

void SelectionDAGBuilder::visitTargetIntrinsic(const CallInst &I, - unsigned Intrinsic) { - bool HasChain = !I.doesNotAccessMemory(); - bool OnlyLoad = HasChain && I.onlyReadsMemory(); + unsigned Intrinsic) { + // Info is set by getTgtMemInstrinsic + TargetLowering::IntrinsicInfo Info; + bool

On Nov 30, 2011, at 1:54 PM, Hal Finkel wrote: > Is there a reason that we don't have a definition for write-only > intrinsics? Specifically, utils/TableGen/CodeGenIntrinsics.h contains: I don't think so, I'm not opposed to it. > If there is no particular reason for the current behavior, then I'll > propose a patch to add a WriteMem tag for intrinsics. Great,

Hi Team, I'm working on a new pure functional language and I'm trying to add GC support for that. Because all vars are immutable, the IR that my frontend generates are all register based, i.e. no alloca, and no readmem, writemem unless accessing/constructing structs. If I use the traditional GC with gcroot intrinsic, it will need to emit more code for liveness tracking, storing the IR

Thanks for reviving this. I completely forgot the details but I resolved this problem. Looking though the code, seems I forked RewriteStatepointsForGC pass, and change it to adding 'gc-livevars' bundle to the call/invoke inst after finding the livevars, instead of changing it to StatepointCall intrinsic. On Wed, Nov 14, 2018 at 11:48 AM Philip Reames <listmail at philipreames.com>

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

On 06/18/2015 09:15 PM, Nick Lewycky wrote: > > 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

Hi, I have two problems regarding the llvm.stackrestore intrinsic. I'm running on 3.0, but a quick test on trunk also showed the same behavior. First problem: --------------- I have code like: tmp1 = call llvm.stacksave() tmp2 = alloca [do some stuff with tmp2] call llvm.stackrestore(tmp1) [some other stuff] tmp3 = call llvm.stacksave() tmp4 = alloca [do some stuff

From: Villmow, Micah Sent: Tuesday, November 06, 2012 1:37 PM To: 'llvm-dev at cs.uiuc.edu' Cc: Guo, Xiaoyi Subject: Bug in SelectionDAG visitTargetIntrinsic We ran into a problem where specifying IntrNoMem was causing our instruction selection to fail with target specific intrinsics. After looking into the code and ISel debug it looks like tablegen and SelectionDAG are using different

Hi, I've tracked the first problem (mentioned in my previous email, quoted below) down further, ending up in the handling of alloca in LoopRotation.cpp (from trunk): // If the instruction's operands are invariant and it doesn't read or write // memory, then it is safe to hoist. Doing this doesn't change the order of // execution in the preheader, but does

Hi, I'd like to draw your attention to http://reviews.llvm.org/D18291, in which I propose a new intrinsic property for intrinsics that are lowered to instructions that mayStore, but are neither mayLoad nor hasSideEffects. This is relevant for AMDGPU, where we have store instructions that don't operate on pointers. The codegen backend understands these perfectly well as stores, and so

Hi, I need to generate a branch instruction from within CodeGenIntrinsic in SparcV9BurgISel.cpp. I generate a few instructions and add them to the mvec vector, and then I need to generate a branch whose target is the first instruction in the vector. I've seen how other portions of the code do this, but they have access to more information than CodeGenIntrinsic. Thanks, Brent

LLVM knows what all the types of the intrinsic functions are; I thought, why are users (including llvm-gcc...) required to duplicate all this information in order to use them? I mean in order to call getOrInsertFunction to get declarations for them. So I wrote this patch, which allows all this code to be generated automatically. Is this a good approach? Dan -- Dan Gohman, Cray Inc. <djg at

Newer Xen versions (at least 4.2) use per_cpu__init_tss instead of init_tss array. Take into account that. Signed-off-by: Daniel Kiper <daniel.kiper-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> diff -Npru crash-6.1.0.orig/x86.c crash-6.1.0/x86.c --- crash-6.1.0.orig/x86.c 2012-11-13 14:45:58.000000000 +0100 +++ crash-6.1.0/x86.c 2012-11-13 14:48:13.000000000 +0100 @@ -5471,9 +5471,16 @@

Is there a way to access the current MachineBasicBlock info from within CodeGenIntrinsic in SparcV9BurgISel.cpp? The arguments are: Intrinsic::ID iid, CallInst &callInstr, TargetMachine &target, and std::vector<MachineInstr*>& mvec, none of which seem to offer access to the current MachineBasicBlock. Brent

It seems that Tablegen is generating intrinsic ID's off by in DAGISel.inc In DAGISel.inc, I have the following pattern: int64_t CN1 = Tmp0->getZExtValue(); // Pattern: (intrinsic_w_chain:f32 103:iPTR, GPRF32:f32:$src0, GPRF32:f32:$src1, GPRF32:f32:$src2) // Emits: (MACRO_FMA_f32:f32 GPRF32:f32:$src0, GPRF32:f32:$src1, GPRF32:f32:$src2) // Pattern complexity = 8 cost

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 >

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

Are you using isTarget = 1 in your intrinsics file? On Apr 14, 2009, at 6:34 PM, Villmow, Micah wrote: > It seems that Tablegen is generating intrinsic ID’s off by in > DAGISel.inc > > In DAGISel.inc, I have the following pattern: > int64_t CN1 = Tmp0->getZExtValue(); > > // Pattern: (intrinsic_w_chain:f32 103:iPTR, GPRF32:f32:$src0, > GPRF32:f32:$src1,

On Mon, 5 Feb 2007, Dan Gohman wrote: > LLVM knows what all the types of the intrinsic functions are; I thought, > why are users (including llvm-gcc...) required to duplicate all this > information in order to use them? I mean in order to call > getOrInsertFunction to get declarations for them. That is an excellent question! :) In the bad old days, we used to allow intrinsics

On Mon, Feb 05, 2007 at 12:28:56PM -0800, Chris Lattner wrote: > On Mon, 5 Feb 2007, Dan Gohman wrote: > > > LLVM knows what all the types of the intrinsic functions are; I thought, > > why are users (including llvm-gcc...) required to duplicate all this > > information in order to use them? I mean in order to call > > getOrInsertFunction to get declarations for