similar to: [LLVMdev] Order of Operations

On Saturday, March 4, 2017, Ryan Taylor <ryta1203 at gmail.com> wrote: > Why you can't still expand it through MUL with a Custom lowering? Or am I > missing something? > > Yes we can but problem occurs when we know that it is shift with constant value than if we return ISD::MUL with constant imm operand than LLVM will convert it to SHL again because the constant will be

Sorry, forgot to add group to CC. On Sun, Nov 20, 2011 at 6:14 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > Cameron, > > To make it less vague, I would ideally like to traverse top down. I > believe what you suggested is what I want, I will have a look at it. > > Currently, I am iterating over the BBs in a Function, so > Function::iterator BBitr=F->begin(),

---------- Forwarded message ---------- From: Ryan Taylor <ryta1203 at gmail.com> Date: Mon, Nov 21, 2011 at 10:30 AM Subject: Re: [LLVMdev] Order of Basic Blocks To: Benjamin Kramer <benny.kra at googlemail.com> This worked, though the RPO_iterator apparently wasn't what I was looking for anyways, it seems it doesn't rreally go top->down. I have a simple example code,

LLVMers, Is there any way to guarantee iteration of the basic blocks from top down or path to path? Currently it looks sort of semi-random, sometimes visiting loop heads first and other times loop tails, is there a way I can visit the BBs top down or path to path? Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL:

Is there a way to cast the rpo_iterator to a basic block pointer? I need to use the functions of the class Basic Block. On Sun, Nov 20, 2011 at 3:15 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > Sorry, forgot to add group to CC. > > On Sun, Nov 20, 2011 at 6:14 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > >> Cameron, >> >> To make it less vague,

Ok, thanks. Even still though I would expect -instcombine (run after lsr) would do this cleanup? On Fri, Oct 19, 2012 at 2:41 PM, Andrew Trick <atrick at apple.com> wrote: > > On Oct 19, 2012, at 2:34 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > That solves the issue but it seems odd to me that instcombine doesn't take > care of it? > > > LSR is

Nick, Unfortunately this doesn't answer my question I don't think. It seems that -instnamer, as you mention, names the instructions but still does not name the local variables. So there really is no way to do this shy of creating (or basically copying) the API from AsmWriter (seems very dedundant to me)? This seems like a large failing? On Fri, Oct 21, 2011 at 7:03 PM, Nick

I am working on llvm gpu backend. The instruction metadata can only get in IR (class instruction). In DAG stage, the instructions are reordered, so I cannot map the metadata to correct instruction if I cannot access instruction from DAG or MachineInstr structure. > On Nov 26, 2017, at 11:02 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > It might be a more useful to know what

Does a transform exist to breakdown the GEP? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111206/e88dddfe/attachment.html>

Eli, Thanks. So I'm unclear exactly which llvm opt will exhibit copy prop. behavior? It seems to me that codegenprepare is doing a useful thing (for me, since I'm just using the llvm IR and not going to backend, providing it's "exposing" and not simply "adding for layout for CodeGen opts" (or something similar to this)? Thanks. On Wed, Oct 17, 2012 at 1:44

That solves the issue but it seems odd to me that instcombine doesn't take care of it? So is this just a setup for the backend? If not, seems like if there is a possibility that lsr could create these redundant operations, should it not clean itself up? Or am I mistaken? On Fri, Oct 19, 2012 at 1:29 PM, Andrew Trick <atrick at apple.com> wrote: > > On Oct 17, 2012, at 1:22 PM,

---------- Forwarded message ---------- From: Ryan Taylor <ryta1203 at gmail.com> Date: Mon, Dec 12, 2011 at 4:58 PM Subject: Re: [LLVMdev] GetElementPtr To: Eli Friedman <eli.friedman at gmail.com> Sorry, So what I'm trying to ask is are the widths given (32, 64) for the index and the offset the widths of the index and offset values or the width of the type they are

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

I'm curious why I am seeing this: *%uglygep18.sum = add i32 %lsr_iv8, %tmp45* %scevgep19 = getelementptr i8* %parBits_017, i32 %uglygep18_sum %scevgep1920 = bitcast i8* %scevgep19 to i16* %tmp78 = load i16* %scevgep1920, align 2 * %uglygep14.sum = add i32 %lsr_iv8, %tmp45* %scevgep15 = getelementptr i8* %extIn_013, i32 %uglygep14_sum %scevgep1516 = bitcast i8* %scevgep15 to i16*

It looks like this problem only exists on nested loops, ideas? On Thu, Jan 12, 2012 at 11:44 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: > Is it not a good idea to try and extract loops that have multiple exits? > > > On Thu, Jan 12, 2012 at 10:44 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: > >> I am trying to use ExtractLoop() but I am getting segFaults:

---------- Forwarded message ---------- From: Ryan Taylor <ryta1203 at gmail.com> Date: Thu, Dec 8, 2011 at 11:13 AM Subject: Re: [LLVMdev] GetElementPtr To: Reid Kleckner <reid.kleckner at gmail.com> There is no support for gep, it's my understanding that it's target-independent, so there's no reason to put the lowering in the target lowering portion is there?

On Oct 19, 2012, at 2:44 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > Ok, thanks. > > Even still though I would expect -instcombine (run after lsr) would do this cleanup? It's valid to run any IR pass after -loop-reduce. So you can try it. -gvn is probably what you're looking for. It isn't something we normally want to do. Turn off LSR if it does bad things on

Hi Ryan, > On Aug 24, 2015, at 6:49 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > Quentin, > > I apologize for the spamming here but in getVR (where VReg is assigned an RC), it calls: > > const TargetRegisterClass *RC = TLI->getRegClassFor(Op.getSimpleValueType()); > VReg = MRI->createVirtualRegister(RC); > > My question is why is it using the

The diff is not only the && and || but also the leading !: diff --git a/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp b/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp index 58f029fbe9fc..7ee06fc153b2 100644 --- a/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp +++ b/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp @@ -659,7 +659,7 @@ void SelectionDAGISel::CodeGenAndEmitDAG() {

Seems llvm cannot pass metadata to MachineInstr, or setting operand description in class Instruction and pass to class MachineInstr. Is it a good idea to extend llvm kernel structure to having this feature? Jonathan > On Nov 27, 2017, at 9:01 PM, Jatin Bhateja <jatin.bhateja at gmail.com> wrote: > > SelectionDAGBuilder contained within SelectionDAGISel has a map (NodeMap) b/w