search for: ismoveimm

...t such as 'long' and 'double'. So I define them like this: def CONSTI64 : InstFOO<(outs GRWideRegs:$dst), (ins i64imm:$src), "const-long $dst, $src", [(set (i64 GRWideRegs:$dst), imm:$src)]>{ let isMoveImm = 1; } def CONSTF64 : InstFOO<(outs GRWideRegs:$dst), (ins f64imm:$src), "const-double $dst, $src", [(set (f64 GRWideRegs:$dst), fpimm:$src)]>{ let isMoveImm = 1; } GRWideRegs can be f64 and i64. However, the &...

...mp, for the above test-case: %0:tgpr, dead $cpsr = tMOVi8 10, 14, $noreg %1:tgpr, dead $cpsr = tMOVi8 20, 14, $noreg $r0 = COPY %0:tgpr $r1 = COPY %1:tgpr IIUC, there are a couple of reasons why this happens: (a) tMOVi8 pattern isn't marked with isRematerializable, isAsCheapAsMove, and isMoveImm. (b) After annotating the pattern with above flags, RegisterCoalescer::reMaterializeTrivialDef still bails out because the above assignment has 2 definitions, with only one live definition. To address this issue, I attached a hackish patch that (a) Marks tMOVi8 pattern with: let isReMaterializable...

...target-independent way? Would it be easier in earlier pre-regalloc MIR, or does that have the same problem because the instructions are already target-specific? >> > > It has enough generic meta information for some kind of instructions but > not for all. MachineInstr has bits for isMoveImm, isMoveReg and mayLoad > that can be useful for recognizing some kind of parameter loading > instructions. But we're not quite sure whether it is enough for > recognizing all of them. For example there is no support for recognizing > X86::LEA instructions with such mechanism (and th...

[+ some folks more knowledgable about the Machine layer than me.] > On Feb 12, 2019, at 5:07 AM, Nikola Prica <nikola.prica at rt-rk.com> wrote: > > Hi, > > I am one of the authors of this feature. On Phabricator, we agreed to > take discussion whether encoding this in IR and threading it through the > compiler or performing a late MIR analysis is the better approach.

...t be easier in earlier pre-regalloc MIR, or does that have the same problem because the instructions are already target-specific? >>>> >>> >>> It has enough generic meta information for some kind of instructions but >>> not for all. MachineInstr has bits for isMoveImm, isMoveReg and mayLoad >>> that can be useful for recognizing some kind of parameter loading >>> instructions. But we're not quite sure whether it is enough for >>> recognizing all of them. For example there is no support for recognizing >>> X86::LEA instruct...

Hello LLVM Developers, We are working on extending currently available register rematerialization to include cases where sequence of multiple instructions is required to rematerialize a value. We had a discussion on this in community mailing list and link is here: http://lists.llvm.org/pipermail/llvm-dev/2016-September/subject.html#104777 >From the above discussion and studying the code we

...ave the same problem because the instructions >>>>>> are already target-specific? >>>>>> >>>>> >>>>> It has enough generic meta information for some kind of instructions but >>>>> not for all. MachineInstr has bits for isMoveImm, isMoveReg and mayLoad >>>>> that can be useful for recognizing some kind of parameter loading >>>>> instructions. But we're not quite sure whether it is enough for >>>>> recognizing all of them. For example there is no support for recognizing >&g...

...>> [(HexagonBARRIER)]>; >> >> @@ -2324,35 +2324,35 @@ def CONST32 : LDInst<(outs IntRegs:$dst), (ins globaladdress:$global), >> (load (HexagonCONST32 tglobaltlsaddr:$global)))]>; >> >> let isReMaterializable = 1, isMoveImm = 1 in >> -def CONST32_set : LDInst<(outs IntRegs:$dst), (ins globaladdress:$global), >> +def CONST32_set : LDInst2<(outs IntRegs:$dst), (ins globaladdress:$global), >> "$dst = CONST32(#$global)", >> [(set IntRegs:$dst,...