search for: connectedvninfoeqclasses

...f %vreg77 from the def at >>>> 312B to the use at 380B seems to be separable from the other >>>> segments.  The reason the above verification failure is not hit at >>>> that point seems to be related to the FIXME in the following snippet >>>> from ConnectedVNInfoEqClasses::Classify(): >>> That dump seems to be well before greedy runs, isn't it? >> >> I'm not sure what you mean.  The attached log contains >> -print-before-all -print-after-all and -debug output starting with the >> coalescer pass. The verification failure is...

...hed debug dump file, just after the greedy allocator runs, the segment of %vreg77 from the def at 312B to the use at 380B seems to be separable from the other segments. The reason the above verification failure is not hit at that point seems to be related to the FIXME in the following snippet from ConnectedVNInfoEqClasses::Classify(): >>>> That dump seems to be well before greedy runs, isn't it? >>> >>> I'm not sure what you mean. The attached log contains -print-before-all -print-after-all and -debug output starting with the coalescer pass. The verification failure is right a...

...hed debug dump file, just after the greedy allocator runs, the segment of %vreg77 from the def at 312B to the use at 380B seems to be separable from the other segments. The reason the above verification failure is not hit at that point seems to be related to the FIXME in the following snippet from ConnectedVNInfoEqClasses::Classify(): > That dump seems to be well before greedy runs, isn't it? I'm not sure what you mean. The attached log contains -print-before-all -print-after-all and -debug output starting with the coalescer pass. The verification failure is right after the first pass of MachineCopyP...

...hed debug dump file, just after the greedy allocator runs, the segment of %vreg77 from the def at 312B to the use at 380B seems to be separable from the other segments. The reason the above verification failure is not hit at that point seems to be related to the FIXME in the following snippet from ConnectedVNInfoEqClasses::Classify(): >> That dump seems to be well before greedy runs, isn't it? > > I'm not sure what you mean. The attached log contains -print-before-all -print-after-all and -debug output starting with the coalescer pass. The verification failure is right after the first pass of M...

...ebug dump file, just after the greedy allocator runs, the segment of %vreg77 from the def at 312B to the use at 380B seems to be separable from the other segments. The reason the above verification failure is not hit at that point seems to be related to the FIXME in the following snippet from ConnectedVNInfoEqClasses::Classify(): // Normal value defined by an instruction. Check for two-addr redef. // FIXME: This could be coincidental. Should we really check for a tied // operand constraint? // Note that VNI->def may be a use slot for an early clobber def. if (const VNInfo...

...hed debug dump file, just after the greedy allocator runs, the segment of %vreg77 from the def at 312B to the use at 380B seems to be separable from the other segments. The reason the above verification failure is not hit at that point seems to be related to the FIXME in the following snippet from ConnectedVNInfoEqClasses::Classify(): That dump seems to be well before greedy runs, isn't it? At a first glance the odd thing there is that the operand of fladd_a32_a32_a32 is rewritten from vreg77 to vreg76, but the vreg77 operand of the BUNDLE is not. Maybe you can find out why that is? - Matthias

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 the verifier. Does this mean that there should never be any ValNos in a LiveInterval that are not connected? In other words should such an LI nev...

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

...rote: >> >> 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 the verifier. Does this mean that there should never be >> any ValNos in a LiveInterval that are not connected? In other words should such an L...

...gt;>>> 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 the verifier. Does this mean that there should never be >>>> any ValNos in a LiveInterval that are not connected? In other words should s...

...ss 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 the verifier. Does this mean that there should never be >>>>>> any ValNos in a LiveInterval that are no...

...e why it looks fine in your example), but it certainly puts needless constraints on the live-ranges. I’m guessing Jakob added that check to make sure the splitting mechanism would create one live-range per connected component. If you’re hitting that problem that means you miss somewhere a call to ConnectedVNInfoEqClasses::Distribute. Cheers, -Quentin On Sep 9, 2019, at 3:36 PM, Arsenault, Matthew <Matthew.Arsenault at amd.com<mailto:Matthew.Arsenault at amd.com>> wrote: 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...

...bjc-fragile-abi -fdiagnostics-show-option -o .libs/filem_rsh_module.o -x c ../../../../../openmpi-1.6.3/orte/mca/filem/rsh/filem_rsh_module.c 0 libLLVM-3.1.so 0x00002b989f3e80df 1 libLLVM-3.1.so 0x00002b989f3e8827 2 libpthread.so.0 0x000000328280ebe0 3 libLLVM-3.1.so 0x00002b989ec09c36 llvm::ConnectedVNInfoEqClasses::Distribute(llvm::LiveInterval**, llvm::MachineRegisterInfo&) + 342 4 libLLVM-3.1.so 0x00002b989ec1af75 llvm::LiveRangeEdit::eliminateDeadDefs(llvm::SmallVectorImpl<llvm::MachineInstr*>&, llvm::ArrayRef<unsigned int>) + 949 5 libLLVM-3.1.so 0x00002b989ebf2142 6 libLLVM-3.1....