similar to: [LLVMdev] Flags/ConditionCode Model is broken

On Mar 22, 2009, at 7:53 AM, someguy wrote: > Hi all, > > I've spent the day trying to understand setcc/select_cc intricacies, > and I thought I should mention that so far as I can tell, the modeling > of CPU flags, condition codes and therefore conditional instructions > seems pretty broken. > > On the one hand there are the SDNPInFlag/SDNPOutFlag node properties >

> > > That's not it at all. These model instructions reading / writing > MVT::Flag a value. That just mean from the scheduler's point of view > the node that produces a MVT::Flag and the user have to be scheduled > together. Wow. That's just super confusing. So SDNPInFlag/SNDPOutFlag is used only for scheduling? I think you're misunderstanding ISD::SETCC.

Hi, What does it mean if a custom Node in the instructions description file is declared to have a Chain? Looking at different backends, I have the impression that it describes some sort of side effect and usually used for nodes affecting the control flow. But I'm not quite sure. Can someone describe the semantics of this property and also what is a typical usage of it? In particular, I have

I think so. If you are defining your own SDNode's, you need to specify one as producing a flag, i.e. SDNPOutFlag; the other will be reading a flag, i.e. SDNPInFlag. Evan On Oct 29, 2008, at 2:55 AM, sanjiv gupta wrote: > def : Pat <(A), (B (C))>; > > can I connect B and C using a flag here? > > TIA, > -Sanjiv > _______________________________________________

On Thu, 2008-10-30 at 08:51 -0700, Evan Cheng wrote: > I think so. If you are defining your own SDNode's, you need to specify > one as producing a flag, i.e. SDNPOutFlag; the other will be reading a > flag, i.e. SDNPInFlag. > > Evan > The problem is that B produces two values: i8, flag. And I would like to connect C using the flag of B and not by i8. > On Oct 29,

> On Wed, 4 Oct 2006, Roman Levenstein wrote: > >> You can add the line > >> setOperationAction(ISD::SELECT, MVT::i32, Expand); > >> to the constructor of you TargetLowering class. See the current > >> backend for an example. > > > > I actually tried it first. But then if, I remember correctly, > SELECT > > nodes were expanded into

On Thu, 5 Oct 2006, Roman Levenstein wrote: >> Check out how the sparc or powerpc backends handle this. They lower >> to a >> select_cc pseudo-op that expands to an if/then/else control flow. > > Thanks! The hint about a pseudo-op was really good. After I realized how > it works, I started the implementation of SELECT_CC using this approach. > Hopefully, I can

def : Pat <(A), (B (C))>; can I connect B and C using a flag here? TIA, -Sanjiv

Eli, Thanks for the tips. I've been able to get something working using a custom instruction inserter, however, I'm still having the problem of linking together the setcc and the select_cc commands. I want to turn the setcc into a comparison and use the results in the select_cc register. However, the comparison information is in the select_cc instruction and the result of the comparison

I attempt to optimize the use of the ‘CMP’ instruction on my architecture by removing the instruction instances where the Status Register already had the correct status flags. The cmp instruction in my architecture is the typical one that compares two registers, or a register with an immediate, and sets the Status Flags accordingly. I implemented my ‘cmp’ instruction in LLVM by custom lowering

On Tue, Mar 15, 2016 at 2:21 PM, Krzysztof Parzyszek via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 3/15/2016 4:16 PM, Rail Shafigulin via llvm-dev wrote: > >> Below is the output of llc with a -debug-only=isel. As you could see the >> output type for load, store, and add changes from v4i32 to i32 during >> legalization. How can I preserve the output type to

Hi Eli, Thank you very much for your response. In fact, I had already tried the X86 approach before, i.e explicitly using the status register. This is the approach that appeals more to me. I left it parked because it also produced some problems (but I left it commented out). So I have now re-lived the code, and it works fine in most cases, but there’s a particular case that causes LLVM to stop

Hi Eli, Thanks again for your reply. I am unsure about implementing the getCrossCopyRegClass for my target. My target does not support or allow moves to and from the SR. The SR exists because it has implicit involvement in some instructions, but it is opaque to the assembler and to the user as a register. I mean, there are no instructions to directly move or read it, or even access it directly.

Hi, I am having some issues with how some of the instructions are being legalized. So this is my intial basic block. The area of concern is the last three instructions. I will pick and choose debug output to keep this small. SelectionDAG has 36 nodes: t0: ch = EntryToken t6: i32,ch = CopyFromReg t0, Register:i32 %vreg507 t2: i32,ch = CopyFromReg t0, Register:i32 %vreg17

But isn't kinda silly that we transform to xor and then we transform it back. What is the advantage in doing so? Also, since we do that method, I now have to introduce setcc patterns for i1 values, instead of being able to just use logical pattern operators like not. -Dilan On Fri, Jul 21, 2017 at 11:00 AM Dilan Manatunga <manatunga at gmail.com> wrote: > For some reason I

OK, so in you case, you want DAG.getSExtOrTrunc(SetCC, DL, SelectVT) to tunc the result from i64 to i32 on 64 bits targets, if I understand correctly. 2 questions: - Why not generating a selectcc node directly ? It avoid having to mess up with intermediate values. - Why calling getSetCCResultType(VT) ? VT is not the type of a parameter of setcc, and this looks incorrect to me. 2014-07-05 0:34

2014-07-08 12:11 GMT-07:00 Matt Arsenault <Matthew.Arsenault at amd.com>: > On 07/07/2014 09:47 PM, deadal nix wrote: > > OK from what I understand, the DAG.getSExtOrTrunc(SetCC, DL, SelectVT) > is unecessary and the SelectVT is nto the right type (as it is called with > incorrect parameter). > > Here is a patch so it won't generate a loop. I ran make check and

Background: The Cell SPU does not have condition registers in the normal sense. It fits the "zero or negative one" model, preferably with an i32 register, which is what getSetCCResultType() will return. Problem: LegalizeTypes promotes i1 to i8 via an i32 setcc, i.e., the generated type legalization is: (i8:truncate (i32:setcc i32:lhs, i32:rhs, ch:cond)) How do I keep

----- Original Message ----- > From: "Nadav Rotem" <nrotem at apple.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "llvmdev at cs.uiuc.edu Dev" <llvmdev at cs.uiuc.edu> > Sent: Wednesday, March 6, 2013 3:40:50 PM > Subject: Re: [LLVMdev] Vector splitting vs widening > > Hi Hal, > > > > > > > The

Hi, I'm investigating an issue with the PTX backend I've come across (latest version from the trunk). Not being very familiar with Selection Dags, it's highly likely that I misunderstand some part of the process. I'd appreciate if someone can point me in the right direction. Here's the LLVM IR that is causing problems (I'm aware this code doesn't do anything