similar to: [LLVMdev] Predicate registers/condition codes question

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

Hi Eli, On Thu, Mar 1, 2012 at 2:21 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > 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

Hi Sebastian, On 22/05/2012 23:25, Sebastian Pop wrote: > Hi Eli, > > On Thu, Mar 1, 2012 at 2:21 PM, Eli Friedman<eli.friedman at gmail.com> wrote: >> 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 >>>

Hi Ivan, On Tue, May 22, 2012 at 5:09 PM, Ivan Llopard <ivanllopard at gmail.com> wrote: > Hi Sebastian, > > On 22/05/2012 23:25, Sebastian Pop wrote: >> So my question is how do we specify that for most of the operations i8 >> should be promoted to i32 and that only a few logical operations are >> legal on i8? > > I think the combo

Hi, On Tue, May 22, 2012 at 11:35 PM, Sebastian Pop <spop at codeaurora.org> wrote: > Hi Ivan, > > On Tue, May 22, 2012 at 5:09 PM, Ivan Llopard <ivanllopard at gmail.com> wrote: >> Hi Sebastian, >> >> On 22/05/2012 23:25, Sebastian Pop wrote: >>> So my question is how do we specify that for most of the operations i8 >>> should be promoted

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

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

Bill Wendling wrote: > On Sep 29, 2010, at 12:36 AM, Heikki Kultala wrote: > >> On 29 Sep 2010, at 06:25, Heikki Kultala wrote: >> >>> Our architecture has 1-bit boolean predicate registers. >>> >>> I've defined comparison >>> >>> def NErrb : InstTCE<(outs I1Regs:$op3), (ins I32Regs:$op1,I32Regs:$op2), "", [(set

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

On 29 Sep 2010, at 06:25, Heikki Kultala wrote: > Our architecture has 1-bit boolean predicate registers. > > I've defined comparison > > > def NErrb : InstTCE<(outs I1Regs:$op3), (ins I32Regs:$op1,I32Regs:$op2), "", [(set I1Regs:$op3, (setne I32Regs:$op1, I32Regs:$op2))]>; > > > > > But then I end up having the following bug: > >

On Sep 29, 2010, at 12:36 AM, Heikki Kultala wrote: > On 29 Sep 2010, at 06:25, Heikki Kultala wrote: > >> Our architecture has 1-bit boolean predicate registers. >> >> I've defined comparison >> >> def NErrb : InstTCE<(outs I1Regs:$op3), (ins I32Regs:$op1,I32Regs:$op2), "", [(set I1Regs:$op3, (setne I32Regs:$op1, I32Regs:$op2))]>;

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

On Sep 30, 2010, at 2:13 AM, Heikki Kultala wrote: > Bill Wendling wrote: >> On Sep 29, 2010, at 12:36 AM, Heikki Kultala wrote: >> >>> On 29 Sep 2010, at 06:25, Heikki Kultala wrote: >>> >>>> Our architecture has 1-bit boolean predicate registers. >>>> >>>> I've defined comparison >>>> >>>> def

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

Salut Sebastian! On 01/06/2012 18:19, Sebastian Pop wrote: > Salut Ivan, > > On Fri, Jun 1, 2012 at 7:22 AM, Ivan Llopard<ivanllopard at gmail.com> wrote: >> Hi Sebastian, >> >> Le 25/05/2012 18:54, Sebastian Pop a écrit : >>> On Thu, May 24, 2012 at 5:40 PM, Sebastian Pop<spop at codeaurora.org> wrote: >>>> On Thu, May 24, 2012 at

Salut Ivan, On Fri, Jun 1, 2012 at 7:22 AM, Ivan Llopard <ivanllopard at gmail.com> wrote: > Hi Sebastian, > > Le 25/05/2012 18:54, Sebastian Pop a écrit : >> On Thu, May 24, 2012 at 5:40 PM, Sebastian Pop<spop at codeaurora.org>  wrote: >>> On Thu, May 24, 2012 at 5:06 PM, Hal Finkel<hfinkel at anl.gov>  wrote: >>>> Sebastian,

On Sun, Jun 3, 2012 at 7:11 AM, Ivan Llopard <ivanllopard at gmail.com> wrote: >> So the solution that I was investigating looks like this: >> >>      for (unsigned int i = 0; i<  ISD::BUILTIN_OP_END; ++i) { >>        switch (i) { >>        // By default all operations on i8 have to be promoted to i32. >>        default: >>        

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

On 07/08/2014 03:20 PM, Matt Arsenault wrote: > Alternatively maybe this should only be done if the setcc type is the > same as the sext result? I think we should actually do this. If you need to convert the setcc result after, you aren't really gaining anything by doing this transformation -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi Sebastian, Le 25/05/2012 18:54, Sebastian Pop a écrit : > On Thu, May 24, 2012 at 5:40 PM, Sebastian Pop<spop at codeaurora.org> wrote: >> On Thu, May 24, 2012 at 5:06 PM, Hal Finkel<hfinkel at anl.gov> wrote: >>> Sebastian, >>> >>> First, it might be useful to look at what is done in the PowerPC >>> backend. PPC also has condition