search for: armbaseinstrinfo

...in low-register-pressure situations, it will refuse to hoist "cheap" instructions out of loops. By default, when an itinerary is available, this means that all of the defined operands are available in at most 1 cycle. ARM overrides this, and provides this more-customized definition: bool ARMBaseInstrInfo:: hasLowDefLatency(const InstrItineraryData *ItinData, const MachineInstr *DefMI, unsigned DefIdx) const { if (!ItinData || ItinData->isEmpty()) return false; unsigned DDomain = DefMI->getDesc().TSFlags & ARMII::DomainMask; if (DDomain == ARMII::DomainGeneral)...

..., pred:0, pred:%CPSR; mem:LD4[%0] We can clearly see that the _LDRrs_ is still there. As a result, after BB#9 and BB#8 have been merged into BB#7, the _LDRs_ instruction is done twice when the "positive" path is taken. My current fix is the following: > @@ -408,7 +408,8 @@ unsigned ARMBaseInstrInfo::removeBranch(MachineBasicBlock &MBB, > return 0; > > if (!isUncondBranchOpcode(I->getOpcode()) && > - !isCondBranchOpcode(I->getOpcode())) > + !isCondBranchOpcode(I->getOpcode()) && > + !isIndirectBranchOpcode(I->getOpcode())) > re...

Hi, there! There are situations where a machine basic block has to be split into two machine basic blocks, e.g., to place a constant pool entry or to fix a conditional branch so that its target is within its range (https://reviews.llvm.org/D38918). However, it doesn't appear to be straightforward how the control flow graph should be updated when a machine basic block is split,

...st combine them explicitly. 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 > >

...as I can figure it, the relocation constants in (ARM|X86)Relocations.h are used only in ARMCodeEmitter, and X86CodeEmitter.cpp respectively - and on X86 only materialized in the JIT case for the X86) Are these relocation values for X86 deemed to be kosher for MC? I was made curious by a comment in ARMBaseInstrInfo.h:166 saying that the ARMCodeEmitter should go away - Since this comment was describing a constant used in the JIT side for playing with the address computation that used the reloc enums defined in ARMRelocations.h, it makes me believe that the ultimate plan is for (ARM|X86)CodeEmitter.[ch]pp to b...

...through the MCSchedModel interface. For example, predicate code coud use the TargetInstrInfo interface to obtain extra description for MachineInst objects. This is what happens for ARM targets, where the `PredicateProlog` casts the TargetInstrInfo object to a ARMBaseInstInfo, and predicated use the ARMBaseInstrInfo interface. Some predicates defined by the cortex-a9 scheduling model select the scheduling class "based on the number of memory addresses in the LDM MachineInstr". Emulating that query would require extra knowledge on the machine memory operands, which we don't have when manipulating...

...through the MCSchedModel interface. For example, predicate code coud use the TargetInstrInfo interface to obtain extra description for MachineInst objects. This is what happens for ARM targets, where the `PredicateProlog` casts the TargetInstrInfo object to a ARMBaseInstInfo, and predicated use the ARMBaseInstrInfo interface. > Some predicates defined by the cortex-a9 scheduling model select the scheduling class "based on the number of memory addresses in the LDM MachineInstr". Emulating that query would require extra knowledge on the machine memory operands, which we don't have when manipula...

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 +

...that is wanting to use SP. It's kind of awkward but does work except in this case of load/store haflword and byte to stack objects. >> > > ARM has a similar problem. The InstrInfo classes should be factored out so that the targets have separate implementations where appropriate. See ARMBaseInstrInfo, ARMInstrInfo, Thumb1InstrInfo and Thumb2InstrInfo. Similarly, the FrameLowering classes. > > If you're sharing that code between the various targets, it sounds like there's some very significant architectural problems in your port, to be honest. > >> Maybe I'm shooting m...

...and mips16 that is wanting to use SP. It's kind of awkward but does work except in this case of load/store haflword and byte to stack objects. > ARM has a similar problem. The InstrInfo classes should be factored out so that the targets have separate implementations where appropriate. See ARMBaseInstrInfo, ARMInstrInfo, Thumb1InstrInfo and Thumb2InstrInfo. Similarly, the FrameLowering classes. If you're sharing that code between the various targets, it sounds like there's some very significant architectural problems in your port, to be honest. > Maybe I'm shooting myself in the foot...

...e the CFG without introducing any false control flow transfers, one needs to determine the target(s) of each terminator. That is what I desire. I am not quite familiar with LLVM, so I am asking whether it is possible to achieve that with the current LLVM API. > Your pseudo-code looks similar to ARMBaseInstrInfo::analyzeBranch. ARMBaseInstrInfo::analyzeBranch also attempts to determine targets of terminators. However, that method is not adequate to achieve what I desire, because it only works for simple conditional/unconditional branches. When it sees something else, e.g., a jump table, it simply reports...

...g to use SP. It's kind of awkward but does work except in this case of load/store haflword and byte to stack objects. >>> >> >> ARM has a similar problem. The InstrInfo classes should be factored out so that the targets have separate implementations where appropriate. See ARMBaseInstrInfo, ARMInstrInfo, Thumb1InstrInfo and Thumb2InstrInfo. Similarly, the FrameLowering classes. >> >> If you're sharing that code between the various targets, it sounds like there's some very significant architectural problems in your port, to be honest. >> >>> Maybe...

Actually, SP is already not in the mips 16 register class but there is some C++ code that is common to mips32, mips64 and mips16 that is wanting to use SP. It's kind of awkward but does work except in this case of load/store haflword and byte to stack objects. Maybe I'm shooting myself in the foot there. I don't know that code too well so maybe I need to look into it. There are

...P. It's kind of awkward but does work except in this case of load/store haflword and byte to stack objects. >>>> >>> >>> ARM has a similar problem. The InstrInfo classes should be factored out so that the targets have separate implementations where appropriate. See ARMBaseInstrInfo, ARMInstrInfo, Thumb1InstrInfo and Thumb2InstrInfo. Similarly, the FrameLowering classes. >>> >>> If you're sharing that code between the various targets, it sounds like there's some very significant architectural problems in your port, to be honest. >>> >>&...

...0] > > We can clearly see that the *LDRrs* is still there. As a result, after > BB#9 and BB#8 have been merged into BB#7, the *LDRs* instruction is done > twice when the "positive" path is taken. > > My current fix is the following: > > @@ -408,7 +408,8 @@ unsigned ARMBaseInstrInfo::removeBranch(MachineBasicBlock > &MBB, > return 0; > > if (!isUncondBranchOpcode(I->getOpcode()) && > - !isCondBranchOpcode(I->getOpcode())) > + !isCondBranchOpcode(I->getOpcode()) && > + !isIndirectBranchOpcode(I->getOpcode()...

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,

...at 03:23, Eli Friedman <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...

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,

...icinc.com <mailto: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 wa...