search for: machineverifi

Could we expose predicates defined in the target InstrInfo.td file to the MachineVerifier? We use BuildMI() to create many instructions after ISEL, but the predicates are not being checked at this point. Thus, I could forget to check the target and build an instruction that is illegal for a specific configuration. In such a case it would be nice if the MachineVerifier could detect thi...

...ndingPadSuccs.size()) So: - the problem exists elsewhere, but is hidden by branch folder optimizations - if the normal successor to an invoke BB is unreachable, it seems reasonable to only have 1 successor, the landing pad. Hence my simple change, making the verifier accept it: --- c/lib/CodeGen/MachineVerifier.cpp +++ w/lib/CodeGen/MachineVerifier.cpp @@ -590,7 +590,11 @@ MachineVerifier::visitMachineBasicBlockBefore(const MachineBasicBlock *MBB) { } } else if (TBB && !FBB && Cond.empty()) { // Block unconditionally branches somewhere. - if (MBB->succ_size() !...

...ct everything must be legal. >> >> Targets can inject passes between the generic passes, i.e., they may inadvertently break the assumptions made by the generic passes. >> We need to have a simple way to catch that. >> >> >> ** Problem ** >> >> The MachineVerifier has not way to know when it is running. For instance, it is impossible to check that there are no virtual registers left after register allocation because it does not know that it is run after register allocation. In such bad situation, we would probably be hitting a crash/assert in the MC layer...

I'm working on getting an out of tree target machine verifier clean. This has found some nasty bugs so I'd like to continue with it. One instance of bad machine code is "Using an undefined physical register". This arises whenever undef propagates to a machine instruction. Usually this means the input was meaningless - e.g. call an undefined address. Other times it's a

Hi Quentin, I get following error from MachineVerifier: # End machine code for function f. *** Bad machine code: Missing mayLoad flag *** which comes from: // Check the MachineMemOperands for basic consistency. for (MachineMemOperand *Op : MI->memoperands()) { if (Op->isLoad() && !MI->mayLoad()) report("Missing may...

...to the loop: %vreg368<def> ... Inside loop: %vreg520<def> = COPY %vreg368 %vreg568<def,tied1> = add %vreg341<tied0>, %vreg520<kill> => was coalesced into => %vreg568<def,tied1> = add %vreg341<tied0>, %vreg368<kill> MachineVerifier then complained: *** Bad machine code: Virtual register killed in block, but needed live out. *** The kill flag for %vreg368 is incorrect, and is cleared by this patch. This is similar to the clearing done at the end of MachineSinking::SinkInstruction(). --- lib/CodeGen/MachineSink.cpp | 5 ++++...

Hi, While working on https://reviews.llvm.org/D79785, we wanted to define foldMemoryOperandImpl hook for Thumb1, that folds load, indirect call to direct call tLDRpci, tBLX -> tBL. This triggered an assertion error with expensive checks turned on in MachineVerifier because the newly created tBL insn by Thumb1InstrInfo::foldMemoryOperandImpl had memory operands of LoadMI attached by TargetInstrInfo::foldMemoryOperand, which is done unconditionally: // Copy the memoperands from the load to the folded instruction. if (MI.memoperands_empty()) { NewMI->set...

Hi all, I'm getting this error: "Virtual register defs don't dominate all uses". It comes from llvm/lib/CodeGen/MachineVerifier.cpp:2138 I don't understand what it means. Does anyone know? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190416/f2eef252/attachment.html>

...FunctionPass - MachineFunctionPrinterPass - MachineInstrBundle - MachineInstr - MachineLICM - MachineLoopInfo - MachineModuleInfo - MachineModuleInfoImpls - MachinePassRegistry - MachinePostDominators - MachineRegisterInfo - MachineScheduler - MachineSink - MachineSSAUpdater - MachineTraceMetrics - MachineVerifier Are there any files in this list that should not be moved? Any others that should be added? Any suggestions on which of these modules would be a good place to start? One question of procedure... Back in 2010 and 2011, I had commit rights on the LLVM svn repository because of work I was doing on...

...Y %vreg368 >>> %vreg568<def,tied1> = add %vreg341<tied0>, %vreg520<kill> >>> >>> => was coalesced into => >>> >>> %vreg568<def,tied1> =add%vreg341<tied0>, %vreg368<kill> >>> >>> MachineVerifierthen complained: >>> *** Bad machine code: Virtual register killed in block, but needed live out. *** >>> >>> The kill flag for %vreg368 is incorrect, and is cleared by this patch. >>> >>> This is similar to the clearing done at the end of >>&gt...

...t; - MachineInstr > - MachineLICM > - MachineLoopInfo > - MachineModuleInfo > - MachineModuleInfoImpls > - MachinePassRegistry > - MachinePostDominators > - MachineRegisterInfo > - MachineScheduler > - MachineSink > - MachineSSAUpdater > - MachineTraceMetrics > - MachineVerifier I *think* the goal here is to minimize the amount of code that gets linked into certain machine-code level tools. If that is the goal, then you only want the modules for Machine IR, and maybe some core analysis passes. The “Machine” modules you listed above include machine code analysis or tran...

...e and in the langref seems to pertain more to constant values and virtual registers. What I really want to achieve is a push-pop of a register to have a temporary to work with, without having to check if this register is defined or not. However, whenever the reg is not defined before the push, the MachineVerifier complains about that. If I add RegState::Undef to the push, the verifier complaint goes away, but I worry that this might be unsafe. I would like "Undef" for physical registers to mean "we don't care if this register has been defined or not", but perhaps it means "th...

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

On Dec 27, 2017 2:00 PM, "Matt Arsenault" <arsenm2 at gmail.com> wrote: > On Dec 26, 2017, at 18:42, Sean Silva via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > Thanks! That looks like a winning approach. > > I swear I grepped around for ISD::Constant but for some reason never found this code. I think maybe I was searching for ISD::Constant with

...ive-in lists on basic blocks, and kill flags on register operands. Simply put, a register is live from a <def> operand to a <use,kill> operand. It must not be used when it isn't live. The rules get tricky when sub-registers are involved. Your best bet for documentation is to read MachineVerifier.cpp and perhaps RegisterScavenging.cpp. If you are rearranging instructions, you must make sure that any kill flags are moved to the last instruction using a register. /jakob

...o op to %EAX<def> = MOV32rr %R9D Because of "-mcpu-atom", post RA scheduling is enabled, so is post RA liveness tracking. Because the destination has been changed to EAX from RAX in transforming the SUBREG_TO_REG pseudo op into a MOV32rr, liveness checking fails in MachineVerifier.cpp. Would anyone be able to comment on why the SUBREG_TO_REG conversion changes the destination register and/or to suggest how this problem might best be fixed? Thanks! Preston -- Preston Gurd <preston.gurd at intel.com> Intel Waterloo SSG/DPD/ECDL/DMP -------------- next part ---...

...he register coalescer? I am trying to understand the setting to help debugging the problem. Also, what does -debug-only=regalloc tell you? Thanks, -Quentin > > thanks, > > Jonas > > On 2015-04-17 18:52, Quentin Colombet wrote: >> 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 <mailto:jonas.paulsson at ericsson.com>> wrote: >>> >>> Hi, >>> &...

Sorry, I meant to say, I added code to prevent llc from running machine verifier after delay slots are filled. MipsInstrInfo::AnalyzeBranch generates incorrect results after delay slots are filled. Also, it seems that code in MachineVerifier.cpp wasn't written with architectures that have delay slots in mind. On Wed, Apr 25, 2012 at 11:59 AM, Akira Hatanaka <ahatanak at gmail.com> wrote: > Hi Anton, > > I ran llc with -verify-coalescing. There were no error messages. > Then I added code in MipsPassConfig::addP...

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

Hi, I wonder if live-in lists can be trusted to be accurate during register allocation / foldMemoryOperandImp(). On SystemZ, a compare register-register which has one of the registers spilled can fold that reload into a compare register-memory instruction. In order to do this also with the first (LHS) register, the operands must be swapped. This can only reasonably be done when all the CC