search for: optimizecompareinstr

Ok, thank you, I will implement it then. As far as I see this optimization should be done in AArch64LoadStoreOptimizer, is it right? From: Eli Friedman [mailto:efriedma at quicinc.com] Sent: Thursday, November 21, 2019 11:55 PM To: Kosov Pavel <kosov.pavel at huawei.com>; LLVM Dev <llvm-dev at lists.llvm.org> Subject: RE: [llvm-dev] [ARM] Peephole optimization ( instructions tst +

...plicitly. Okay, will do. > > You may also want to look at ARM's use of optional defs for > instructions that can optionally set the flags. As far as I can tell, this makes it the job of the C++ code to add the implicit register definition (as is done at the end of ARMBaseInstrInfo::optimizeCompareInstr). Is that right? Thanks again, Hal > > /jakob > >

On Tue, Mar 17, 2015 at 6:14 PM, Tim Northover <t.p.northover at gmail.com> wrote: >> As a simplification, the compiler deals almost exclusively in pseudo >> instructions. By x86 analogy, using pseudos to unfold a TEST32rm into >> MOV32rm + TEST32rr means I can skip the complex operand fitting effort >> needed to pick specific machine instructions. There are many

Hi Quentin, Yes, the code allows to process connected instructions. Although it should be taken into account that the instruction next to the current processed instruction must never be erased because this invalidates iterator. I've been fixing a bug in AArch64InstrInfo::optimizeCompareInstr: instructions are converted into S form but it's not checked that they produce the same flags as CMP. The bug exists upstream as well. Together with the fix I want to add some peephole rules for combinations CMP+BRC and CMP+SEL. In the context of optimizeCmpInstr I have all information about Cm...

On Apr 12, 2013, at 2:06 AM, Hal Finkel <hfinkel at anl.gov> wrote: > In the PPC backend, there is a "helper" class used to define instructions that implicitly define a condition register: > > class isDOT { > list<Register> Defs = [CR0]; > bit RC = 1; > } > > and this gets used on instructions such as: > > def ADDICo : DForm_2<13,

...dman <efriedma at quicinc.com> wrote: > > There are basically two possible approaches here. > > One approach is to just wait until after isel to handle this: check for an addition instruction immediately followed by an cmp; then erase the cmp. See, for example, ARMBaseInstrInfo::optimizeCompareInstr. > > Another, you make a dedicated target-specific ISel node that produces two results: essentially, one is the result of the arithmetic, and the other is the status register. See, for example, X86TargetLowering::LowerBRCOND. > > I don't think you'd want to try to do anything...

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

Hi, In the PPC backend, there is a "helper" class used to define instructions that implicitly define a condition register: class isDOT { list<Register> Defs = [CR0]; bit RC = 1; } and this gets used on instructions such as: def ADDICo : DForm_2<13, (outs GPRC:$rD), (ins GPRC:$rA, s16imm:$imm), "addic. $rD, $rA, $imm", IntGeneral,

...to:efriedma at quicinc.com>> wrote: > > There are basically two possible approaches here. > > One approach is to just wait until after isel to handle this: check for an addition instruction immediately followed by an cmp; then erase the cmp. See, for example, ARMBaseInstrInfo::optimizeCompareInstr. > > Another, you make a dedicated target-specific ISel node that produces two results: essentially, one is the result of the arithmetic, and the other is the status register. See, for example, X86TargetLowering::LowerBRCOND. > > I don't think you'd want to try to do anythi...

On Feb 17, 2011, at 10:35 PM, Вадим Марковцев wrote: > Hello everyone, > > I've added the "S" suffixed versions of ARM and Thumb2 instructions to tablegen. Those are, for example, "movs" or "muls". > Of course, some instructions have already had their twins, such as add/adds, and I leaved them untouched. Adding separate "s" instructions is

Hi, I find it's quite strange how condition dependent instructions are processed in PeepholeOptimizer::runOnMachineFunction: 01577 if ((isUncoalescableCopy(*MI) && 01578 optimizeUncoalescableCopy(MI, LocalMIs)) || 01579 (MI->isCompare() && optimizeCmpInstr(MI, &MBB)) || 01580 (MI->isSelect() && optimizeSelect(MI,

Hello everyone, I've added the "S" suffixed versions of ARM and Thumb2 instructions to tablegen. Those are, for example, "movs" or "muls". Of course, some instructions have already had their twins, such as add/adds, and I leaved them untouched. Besides, I propose the codegen optimization based on them, which removes the redundant comparison in patterns like orr