similar to: [LLVMdev] Branch-like intrinsic

On Mon, 14 Apr 2008, Edward Lee wrote: > Is there a way to implement an intrinsic that looks like a conditional > branch so that it has 2 edges to 2 basic blocks? No. All control flow operators must be terminator instructions. > Taking a step back, I'm trying to make a special branch where Passes > treat it just like a regular conditional branch except that it's >

On Mon, Apr 14, 2008 at 5:11 PM, Chris Lattner <sabre at nondot.org> wrote: > Why not something like: > %x = llvm.myintrinsic() > br i1 %x, label %T, label %F Right. That's exactly what I meant in the last paragraph of the original message. The reason for not wanting this is that %x actually always turns out to be 1 (on architectures that support it), so %T is always

On Mon, Apr 14, 2008 at 5:37 PM, Chris Lattner <sabre at nondot.org> wrote: > The code generator does CFG simplification to handle cases where blocks > become dead during lowering. Oh... is there a way to prevent that from happening? While %x is always 1 and %T is always taken, %F isn't actually dead. There would be a way (with another intrinsic) for control to flow into %F at

On Mon, 14 Apr 2008, Edward Lee wrote: > On Mon, Apr 14, 2008 at 5:11 PM, Chris Lattner <sabre at nondot.org> wrote: >> Why not something like: >> %x = llvm.myintrinsic() >> br i1 %x, label %T, label %F > Right. That's exactly what I meant in the last paragraph of the > original message. > > The reason for not wanting this is that %x actually

On Mon, Apr 14, 2008 at 2:50 PM, Edward Lee <eslee3 at uiuc.edu> wrote: > On Mon, Apr 14, 2008 at 5:37 PM, Chris Lattner <sabre at nondot.org> wrote: > > The code generator does CFG simplification to handle cases where blocks > > become dead during lowering. > Oh... is there a way to prevent that from happening? While %x is > always 1 and %T is always taken,

Hi, I will try to explain by giving an example. Let's say that I have an intrinsic: int llvm.myintrinsic(int) I have a function: int myintrinsic_handler(int) When %var = call int %llvm.myintrinsic( int %arg ) is met in the code, I want the code generator put in its place: a call to function "myintrinsic_handler" (i.e. %var = call int %myintrinsic_handler( int %arg ) ) or

On Mon, Apr 14, 2008 at 5:02 PM, Bill Wendling <isanbard at gmail.com> wrote: > Then that flow would be explicit in the CFG, right? Then %F wouldn't > be dead, I'm assuming. Right. That's why I used a conditional branch after the intrinsic, but it sounds like the CFG simplification pass after lowering will optimize it away and no longer have the flow explicit. (To the

On Sat, 2007-03-31 at 12:38 -0800, Chris Lattner wrote: > >> 3. Can I introduce an intrinsic that is actually a call to my function > >> that implements the logic? I suppose it is possible but unfortunately > >> I couldn't figure it out. For example, in GCC we can write an > >> intrinsic that translates to a C code. > > > > As part of PR1297

Matt, The added intrinsic in DAG looks like: 0xbedb698: i32 = llvm.MyIntrinsic 0xbedb200, 0xbedac18 [ORD=4] The builtin in DAG looks like: 0xbedb2a8: i32,ch = llvm 0xbedb158:1, 0xbedb200, 0xbedb158 [ORD=7] [ID=16] The only difference I'm seeing is the extra operand, which is a 'ch' from a load. On Tue, Feb 2, 2016 at 3:55 PM, Matt Arsenault <arsenm2 at gmail.com>

>> 3. Can I introduce an intrinsic that is actually a call to my function >> that implements the logic? I suppose it is possible but unfortunately >> I couldn't figure it out. For example, in GCC we can write an >> intrinsic that translates to a C code. > > As part of PR1297 (http://llvm.org/PR1297) I am about to make this > happen. There are certain kinds of

The intrinsic ID is an int, not a float. —escha > On Jun 24, 2016, at 7:49 AM, Ryan Taylor via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > given the following C code: > > float b=16, a=0; > int main() { > float a = sqrt(b); > return0; > } > > I'm trying to lower FSQRT down, but getting a casting issue, my code is: > > SDValue

I've tried all the types (both for result and Intrinsic ID), can't seem to find what cast is causing the issue here. On Fri, Jun 24, 2016 at 11:47 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: > That's what I thought but I got the same error with: > > DAG.getNode(ISD::INTRINSIC_WO_CHAIN, DL, VT, > DAG.getTargetConstant(Intrinsic::my_intrinsic, DL, MVT::i16), LHS);

On Mon, 14 Apr 2008, Edward Lee wrote: > On Mon, Apr 14, 2008 at 6:00 PM, Chris Lattner <sabre at nondot.org> wrote: >> You can change the code generator or not run the block layout pass. > Ok thanks for the help. I'll try finding where to twiddle this. > Perhaps explicitly check if the branch's condition is the call to my > intrinsic. > > Or is there another

Chris, Thanks for the suggestions. On 8/22/05, Chris Lattner <sabre at nondot.org> wrote: > On Fri, 19 Aug 2005, Michael McCracken wrote: > > > I've been thinking of adding an instruction, and I'm following the > > advice in the docs to consult the list before doing something rash. > > Always a good idea! :) Instead of adding an instruction, I'd

On 8/23/05, Chris Lattner <sabre at nondot.org> wrote: > On Tue, 23 Aug 2005, Michael McCracken wrote: > >> Okay... this is tricky. Anything that will bind to variables will > >> prevent modification to the variable. > > > > I see - so if I wanted to use my earlier approach, I'd need to change every > > optimization and analysis to treat the

Matt, This seems to generate llvm.my_intrinsic just fine in the DAG, so no DAG errors; however, it won't match. For example, if I call the intrinsic from C, the DAG node looks to be named the same in dotty file but it won't match... am I missing something? I've done it exactly the way it was done above. The DAG looks great but it won't match. Did I miss something? Thanks.

On Tue, 23 Aug 2005, Michael McCracken wrote: >> Okay... this is tricky. Anything that will bind to variables will >> prevent modification to the variable. > > I see - so if I wanted to use my earlier approach, I'd need to change every > optimization and analysis to treat the 'marker' instructions specially as > instructions that don't modify their

On Fri, 19 Aug 2005, Michael McCracken wrote: > I've been thinking of adding an instruction, and I'm following the > advice in the docs to consult the list before doing something rash. Always a good idea! :) Instead of adding an instruction, I'd suggest adding an intrinsic. You can mark intrinsics as not reading/writing to memory (see lib/Analysis/BasicAliasAnalysis.cpp for

I've been thinking of adding an instruction, and I'm following the advice in the docs to consult the list before doing something rash. What I want to do is provide a way to identify variable names and source locations that doesn't affect the effectiveness of optimizations. This is not the same problem as supporting debug info, because I don't care about being able to look up

Hi, is there any standard way to figure out the label of the basic block where a conditional branch merges? If we have a branch statement without an else part this is straightforward: br i1 %cmp, label %if.then, label %if.end, !dbg !24 We only need to check the operand names whether they contain "end". However things are getting more complex when there is an else branch and in