search for: aarch64instrinfo

One place to look might be in the MachineOutliner target hooks in X86InstrInfo and AArch64InstrInfo. The MachineOutliner runs extremely late in the pass pipeline so it might be a good place to look for some inspiration. Of course, because this is *extremely late* it might not do *exactly* what you need. (e.g, this is post-register allocation, post frame-lowering, etc.) - Jessica > On May 4,...

Hi, while implementing SystemZTTI:getCacheSize(), it became clear that there really isn't a simple way to just ask the Subtarget for the current subtarget machine model. I was thinking like something of an enum that would also reflect the subtarget series (and would allow >= and similar operations). I would like to ask what the ideas are on how this should be done best. Some

Hi! I'm making a strange observation in my backend, that ends in illegal code: Version 1: - I lower FrameIndex to TargetFrameIndex (nothing special) - I generate a special address-register ADD instruction in eliminateFrameIndex() to write FramePointer + offset into a new address-register - I use explicit load and store and address-registers in my target instruction patterns: eg (store

...t;]>; ``` Predicate WriteZPred is used to check if a GPR instruction is a zero-idiom. The rationale is that zero-idioms have zero latency and don't consume processor resources. The predicate logic is defined by method `isGPRZero()`, which is accessible through the TII object (i.e. a `const AArch64InstrInfo *`). Below is the definition of `isGPRZero` in AArch64/AArch64InstrInfo.cpp: ``` // Return true if this instruction simply sets its single destination register // to zero. This is equivalent to a register rename of the zero-register. bool AArch64InstrInfo::isGPRZero(const MachineInstr &MI) {...

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 al...

Martin, Thanks for your suggestion. I look at these tests, try to make them work for COFF. Adam On 2019. 10. 02. 12:23, Martin Storsjö wrote: > On Wed, 2 Oct 2019, Adam Kallai wrote: > >> I'm working Chromium targeting Windows on ARM64 platform. As a part >> of this work I ran into an issue related to llvm in Swiftshader. >> >> Currently fixup_aarch64_movw

...should have latencies set to "1" while being otherwise exactly the same as normal load and store instructions. Various assertions fire (even different ones for the same binary, maybe something is uninitialized) and I can't understand what's wrong. Related pieces added by me: to AArch64InstrInfo.td: let isReMaterializable = 1 in { def FakeLoad64 : Pseudo<(outs GPR64:$Rt), (ins GPR64sp:$Rn, GPR32:$Rm, ro_Wextend64:$extend), []>; def FakeStore64 : Pseudo<(outs), (ins GPR64:$Rt, GPR64sp:$Rn, GPR32:$Rm, ro_Wextend64:$extend), []>; } def AArch64fakeload64 : SDNode&lt...

Hello, I want to add assembly instructions at certain points in a function. This is X86 specific. So I am working in the lib/Target/X86 folder. I create a `MachineFunctionPass` in that folder. I register it in the X86TargetMachine.cpp in addPreEmitPass(). I use BuildMI to insert my own assembly instructions in the MachineFunctionPass. This works and my assembly instructions are inserted at

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,

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 +

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