search for: add_rr

...1 would be the most elegant one. It would have a one to one correspondence with the ARM Architecture Reference Model. For two to work it would be necessary to write custom select code to use the more uncommon addressing options. For three I could use the multiclass feature to implement add_ri and add_rr. The add_ri instruction would use a custom addressing mode for the second operand. Currently I am planning to implement 3 because it looks like to be the easiest to implement. Any comments? Thanks, Rafael

...(part of a single block loop). MI1:: %vreg7:subreg_loreg<def,undef>, %vreg30<def> = POST_LDriuh %vreg30, 2, // Post Inc. Load. Vreg7 is a 64bit reg. MI2:: %vreg7:subreg_hireg<def> = COPY %vreg32:subreg_hireg<kill> // This is the A3 = B0 above. MI3:: %vreg31<def> = ADD_rr %vreg31<kill>, %vreg32:subreg_loreg<kill> // Use the lo subreg that was setup in MI1: .... .... MI4:: %vreg32<def> = COPY %vreg7; //Not trivial because 7 is not killed. This is the Copy C i.e. B1=A3. .... MI5:: Conditional jump back to start of the bloc...

Hello. I come back to this older thread. Again, because of i64immSExt32 I receive TableGen error "Could not infer all types in, pattern!" (exact details written below). So far I'm not able to generate selection code with TableGen for the ADD_r* instructions, etc: def i64immSExt32 : PatLeaf<(imm), [{return

Hi Jakob, Thanks for your reply. > > The <undef> flag goes on NewMI_1 because the virtual register B isn't live > before that instruction. > > But you probably shouldn't be doing this yourself. Your NewMI code isn't in > SSA form because B has multiple definitions. Just use a REG_SEQUENCE > instruction, and let the register allocator do the transformation

On Aug 1, 2012, at 1:53 PM, Jyotsna Verma <jverma at codeaurora.org> wrote: > > Currently, we rely on switch tables to transform between formats. However, > we would like to have a different mechanism to represent these relationships > instead of switch tables. I am thinking of modeling these relations in > HexagonInstrInfo.td file and use TableGen to generate a table with

.../ (Predicate true) Add register immediate - R1 = add(R2, #12) -- \ \---- if (!p0) R1 = add(R2, #12) (predicate false) multiclass Add_rr < IFormat TransformsFrom> { def #NAME# : V2_A2_add, RelationMap < TransformsFrom, Format_rr>; defm _pt : V2_A2_padd, RelationMap < Format_rr, Format_predt, ["rr"]>; defm _pf : V2_A2_padd, RelationMap < Format_rr, Format_predf, ["rr"] >; } multiclas...

...t; would have a one to one correspondence with the ARM Architecture > Reference Model. > > For two to work it would be necessary to write custom select code to > use the more uncommon addressing options. > > For three I could use the multiclass feature to implement add_ri and > add_rr. The add_ri instruction would use a custom addressing mode for > the second operand. > > Currently I am planning to implement 3 because it looks like to be the > easiest to implement. I'm not sure exactly what the constraints you have are, but I'd suggest using a 'complexp...

Hi, I'm looking for some suggestions on a problem related to the Hexagon backend. Hexagon architecture allows instructions in various formats. For example, we have 3 variations of the add instruction as defined below: ADDrr : r1 = add(r2, r3) --> add 2 32-bit registers ADDrr_p : if(p0) r1 = add(r2, r3) --> predicated version of ADDrr instruction, executed when p0 is true ADDrr_np :

...> > MI1:: %vreg7:subreg_loreg<def,undef>, %vreg30<def> = POST_LDriuh %vreg30, > 2, // Post Inc. Load. Vreg7 is a 64bit reg. > MI2:: %vreg7:subreg_hireg<def> = COPY %vreg32:subreg_hireg<kill> > // This is the A3 = B0 above. > MI3:: %vreg31<def> = ADD_rr %vreg31<kill>, %vreg32:subreg_loreg<kill> > // Use the lo subreg that was setup in MI1: > .... > .... > MI4:: %vreg32<def> = COPY %vreg7; //Not trivial > because 7 is not killed. This is the Copy C i.e. B1=A3. > .... > MI5:: Conditi...