similar to: [MachineCopyPropagation] Issue with register forwarding/allocation/verifier in out-of-tree target

> On Sep 26, 2017, at 2:39 PM, Geoff Berry via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi all, > > Mikael reported a machine verification failure in his out-of-tree target with the MachineCopyPropagation changes to forward registers (which is currently reverted). The verification in question is: > > *** Bad machine code: Multiple connected components in live

On 9/26/2017 6:11 PM, Matthias Braun wrote: > >> On Sep 26, 2017, at 2:39 PM, Geoff Berry via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Hi all, >> >> Mikael reported a machine verification failure in his out-of-tree target with the MachineCopyPropagation changes to forward registers (which is currently reverted). The verification in question is:

> On Sep 26, 2017, at 3:33 PM, Geoff Berry <gberry at codeaurora.org> wrote: > > > > On 9/26/2017 6:11 PM, Matthias Braun wrote: >>> On Sep 26, 2017, at 2:39 PM, Geoff Berry via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>> >>> Hi all, >>> >>> Mikael reported a machine verification failure in his out-of-tree target

On 9/26/2017 6:47 PM, Matthias Braun wrote: > >> On Sep 26, 2017, at 3:33 PM, Geoff Berry <gberry at codeaurora.org >> <mailto:gberry at codeaurora.org>> wrote: >> >> >> >> On 9/26/2017 6:11 PM, Matthias Braun wrote: >>>> On Sep 26, 2017, at 2:39 PM, Geoff Berry via llvm-dev >>>> <llvm-dev at lists.llvm.org

> On Sep 26, 2017, at 8:24 PM, Geoff Berry via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 9/26/2017 6:47 PM, Matthias Braun wrote: >>> On Sep 26, 2017, at 3:33 PM, Geoff Berry <gberry at codeaurora.org <mailto:gberry at codeaurora.org> <mailto:gberry at codeaurora.org <mailto:gberry at codeaurora.org>>> wrote: >>> >>>

Hi, anyone know anything about copy propagation? Matthias, I see this was your code originally? Was there some assumptions you made? I'm hitting an assertion in MachineCopyPropagation::isNopCopy: if (Src == PreviousSrc) { assert(Def == PreviousDef); return true; } This code compares two COPY instruction to see whether they are effectively "the same". The assert assumes

Hi, I have come across a csmith generated test case that made the MachineVerifier spit out: *** Bad machine code: Multiple connected components in live interval *** Having looked at what this might mean, it seems that ConnectedVNInfoEqClasses::Classify() was called on the LI in question by the verifier, and that it returned two equivalence classes, instead of just one, which is demanded by

Hi, I’m hitting a machine verifier error in a trivial testcase which I don’t understand. There are 2 dead defs of the same register: --- name: multiple_connected_compnents_dead tracksRegLiveness: true body: | bb.0: dead %0:vgpr_32 = V_MOV_B32_e32 0, implicit $exec dead %0:vgpr_32 = V_MOV_B32_e32 1, implicit $exec ... The live intervals look OK to me with 1 valno

Hi Jonas, Could you file a PR with your test case please? Thanks, -Quentin > On Apr 16, 2015, at 3:50 PM, Andrew Trick <atrick at apple.com> wrote: > >> >> On Apr 16, 2015, at 6:58 AM, Jonas Paulsson <jonas.paulsson at ericsson.com <mailto:jonas.paulsson at ericsson.com>> wrote: >> >> Hi, >> >> I have come across a csmith generated

Hi, I have the following code: %a1<def> = COPY %a0<kill> ... %a0h<def> = COPY %a1l , as input to MachineCopyPropagation. The second copy is illegally erased! This is wrong, because it is the low part of a1 that is copied to the high part of a0. At a first glance, it seems that if (!ReservedRegs.test(Def) && (!ReservedRegs.test(Src) ||

Hi Jonas, When is the MachineVerifier complaining? I mean after which pass? Thanks, -Quentin > On Apr 17, 2015, at 7:17 AM, Jonas Paulsson <jonas.paulsson at ericsson.com> wrote: > > Hi, > > thanks for answering, but the COPY is there already from after isel. It is a copy of a subreg, after a a call returning 64 bits. > > call

Hello all, For my custom processor backend I am trying add some instruction using BuildMI() inside eliminateFrameIndex(). I tried RegScavenger like this: unsigned RegUnused0 = RS->FindUnusedReg(&LASER::GNPRegsRegClass); if (!RegUnused0) RegUnused0 = RS->scavengeRegister(&LASER::GNPRegsRegClass, II, SPAdj); assert(RegUnused0 && "Register scavenger failed");

Hi Jonas, > On Apr 20, 2015, at 4:03 AM, Jonas Paulsson <jonas.paulsson at ericsson.com> wrote: > > Hi Quentin, > > After Simple Register Coalescing. Is the code you have pasted with the PHIs feed to the register coalescer? I am trying to understand the setting to help debugging the problem. Also, what does -debug-only=regalloc tell you? Thanks, -Quentin > >

Forgive me if these questions are naive or if I'm misunderstanding something. I'm certainly very interested in seeing the MachineCopyPropagation patch finally land and stick. 1. Wouldn't function live-ins and reserved registers have started life as physical registers already? For example, wouldn't a live-in be a copy from a physical register to a virtual one allowing the flag to

Hi All, Currently, changing register assignments of definitions after register allocation is not safe because there is no way to know which register definitions were physical registers before RA (e.g. to meet ABI or ISA constraints) and thus should not be changed. I'd like to propose adding a bit to MachineOperand (by overloading the meaning of the IsKill bit for defs, so no extra

I need to use ‘createVirtualRegister’ for a specific case in my ‘eliminateFrameIndex’ function implementation. However, whenever that code is executed, I get the assertion "MachineCopyPropagation should be run after register allocation!” at a later stage. I have seen that at least a couple of backend implementations (including ARM Thumb) create virtual registers in ‘eliminatedFrameIndex’.

If I'm understanding what's going on in this test correctly, what's happening is: * ARMTargetLowering::LowerCall prefers indirect calls when a function is called at least 3 times in minsize * In thumb 1 (without -fno-omit-frame-pointer) we have effectively only 3 callee-saved registers (r4-r6) * The function has three arguments, so those three plus the register we need to hold the

> > PHIElim and TwoAddress passes leave SSA form. > May be a missed something in your code but %vreg48 seems to be there > after PHI elimination. PHIElim tags those kind of registers as being > PHIJoin regs, updating LiveVariables pass, so the regcoalescer is aware > of them (some SSA info is still alive but the reg coalescer will > invalidate that information after

Hi, I have encountered a test case where InlineSpiller generates bad code. A register is reloaded but never spilled, and I suspect a bug in InlineSpiller. A register is live over a loop that also have two inner loops. It is not used or defined over the inner loops. It is split into two sibling registers, where one covers just the inner loops interval, which is then spilled. In spill(),

Hi Quentin, I have tried to find a test case for an official target, but failed. It seems to be a rare case. To do it, I added the 'else' clause in the following: ... if (VNI->def == OrigVNI->def) { DEBUG(dbgs() << "orig phi value\n"); SVI->second.DefByOrigPHI = true; SVI->second.AllDefsAreReloads = false; propagateSiblingValue(SVI); continue;