search for: brconds

Hi everyone, I have the following code (as part of a larger function): %0 = icmp eq i16 %a, 0 ; <i1> [#uses=1] br i1 %0, label %bb1, label %bb I would like to match this with a BRCOND, but all I get is an error message when compiling the above code that say: LLVM ERROR: Cannot yet select: 0x170f200: ch = br_cc 0x170f000, 0x170ed00, 0x170dc60, 0x170ec00, 0x170ef00 [ID=19]

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

I am implementing a new backend and am pretty sure I don't quite understand "the way" one is supposed to implement conditional branches. My target CPU natively supports a conditional branch instruction that accepts a condition to test (equal, less than, etc.), two operands (two registers, or one register and one immediate), and finally a target PC to branch to if the comparison

...ision is a long code sequence we have to insert that has branches within it (test for 0 divisor, etc.) Can't really emit the sequence of instructions via tblgen (can't have labels or BBs). The other alternative is a custom instruction emitter. Life could be easier if I could insert BRCONDs and other branches from within target-dependent lowering -- if I had access to the current MBB. Is this possible or just a FAQ? -scooter

I have a back end which has both scalar and vector registers that alias each other. I'm having a problem generating the ISel from tablegen that appears only when a vector register class is declared to contain integer vectors. At that moment tablegen doesn't seem to be able to infer integer types in patterns that it was able to before, but I'm not clear on why that's the

...> sequence we have to insert that has branches within it (test for 0 > divisor, etc.) Can't really emit the sequence of instructions via > tblgen (can't have labels or BBs). The other alternative is a custom > instruction emitter. > > Life could be easier if I could insert BRCONDs and other branches > from within target-dependent lowering -- if I had access to the > current MBB. > > Is this possible or just a FAQ? It isn't currently possible for a selection dag to represent more than one machine basic block. I think Christopher Lamb had some code that d...

Hi there, I'm having a hard time with promoting operands from i1 to i32 in my backend... I have to register classes, VTs are i1 and i32. The i1 registers are only for predication and conditional jumps, so I want to use them with brcond, setcc. There are no instructions to directly load a value in an i1 register or to copy between i1 and i32, so I need the DAG Legalizing Pass to not generate

Here's our testcase: #include <stdio.h> struct flags { unsigned frog: 1; unsigned foo : 1; unsigned bar : 1; unsigned bat : 1; unsigned baz : 1; unsigned bam : 1; }; int main() { struct flags flags; flags.bar = 1; flags.foo = 1; if (flags.foo == 1) { printf("Pass\n"); return 0; } else {

On 12/21/2016 4:45 PM, Phil Tomson via llvm-dev wrote: > Here's our testcase: > > #include <stdio.h> > > struct flags { > unsigned frog: 1; > unsigned foo : 1; > unsigned bar : 1; > unsigned bat : 1; > unsigned baz : 1; > unsigned bam : 1; > }; > > int main() { > struct flags flags; > flags.bar = 1; >

...insert that has branches within it (test for 0 > > divisor, etc.) Can't really emit the sequence of instructions via > > tblgen (can't have labels or BBs). The other alternative is a custom > > instruction emitter. > > > > Life could be easier if I could insert BRCONDs and other branches > > from within target-dependent lowering -- if I had access to the > > current MBB. > > > > Is this possible or just a FAQ? > > It isn't currently possible for a selection dag to represent more than > one machine basic block. I think Christo...

On Sun, 22 Apr 2007, Christopher Lamb wrote: > I have a back end which has both scalar and vector registers that > alias each other. I'm having a problem generating the ISel from > tablegen that appears only when a vector register class is declared > to contain integer vectors. At that moment tablegen doesn't seem to > be able to infer integer types in patterns that it was

Hi, >> DAGCombiner::visitBRCOND() has code: >> >> SDValue N1 = N->getOperand(1); >> SDValue N2 = N->getOperand(2); >> >> ... >> >> SDNode *Trunc = 0; >> if (N1.getOpcode() == ISD::TRUNCATE&& N1.hasOneUse()) { >> // Look past truncate. >> Trunc = N1.getNode(); >> N1 = N1.getOperand(0);

...the water (having everything promoted up to i32 as a consequence)? Would it be permissible to add a virtual function to TargetLowering such that the target can effectively say, "Really, the setcc is legal, no need to truncate!"? The alternative is to do fairly deep inspection of brconds to eliminate the truncate, which eventually gets expanded into: (i8:sext_in_reg (i8:truncate (i32:setcc ...))) -scooter -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20081212/397249df/attachment.html&g...

On Jan 6, 2009, at 11:37 PM, Scott Michel wrote: > Chris: > > I was trying to avoid using the custom instruction emitter method. > Not as if I didn't look before I asked the question to see if there > was an easier way. Then no, there is no other way. -Chris

Chris: It occurred to me this morning that maybe the general solution to this particular type of problem is a custom/target-dependent DAG inserter pass, analogous to target lowering and DAG legalization. I'm not sure if this pass happens before or after legalization. Worth considering? I suppose the best way to discuss this is to just write the code. However, some preliminary

Hey folks, We are having some difficulty with how we have been representing our predicate registers, and wanted some advice from the list. First, we had been representing our predicate registers as 1 bit (i1). The truth, however, is that they are 8 bits. The reason for this is that they serve as predicates for conditional execution of instructions, branch condition codes, and also as

Hello, Im back trying to finish my backend to a simple RISC cpu SABRE now that most of the tedious process of examining undergraduate students is out of the way. I have managed to describe the registers and the instructions in the architecture and have added support for 32 bit immediates (thanks to Christopher Lamb) as the instruction set only supports 17 bit immediates directly. Could

On Tue, Feb 28, 2012 at 11:17 AM, Tony Linthicum <tlinth at codeaurora.org> wrote: > Hey folks, > > We are having some difficulty with how we have been representing our > predicate registers, and wanted some advice from the list.  First, we > had been representing our predicate registers as 1 bit (i1).  The truth, > however, is that they are 8 bits.  The reason for this is

Given that this is compiled with -O0, would there a way to skip the Optimization of the Type-legalized selection DAG? It's fine until it optimizes the Type-legalized selection DAG into the Optimized Type-legalized selection DAG. Phil On Thu, Dec 22, 2016 at 10:29 AM, Friedman, Eli <efriedma at codeaurora.org> wrote: > On 12/21/2016 4:45 PM, Phil Tomson via llvm-dev wrote: > >