search for: vreg76

...me from re-enabling the copy forwarding patch (I can send you my latest rebased version, but I don't think it is relevant to this problem. See below). > >>> >>>> 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? >>> >>> Sorry, I should have pointed this out before: because the loop over instructions in MachineCopyPropagation is only visiting the BUNDLE instructions themselves (i.e. it does not visit the ins...

...from re-enabling the copy forwarding patch (I can send you my latest rebased version, but I don't think it is relevant to this problem. See below). >> >>> 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? >> >> Sorry, I should have pointed this out before: because the loop over >> instructions in MachineCopyPropagation is only visiting the BUNDLE >> instructions themselves (i.e....

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

...ed. In spill(), analyzeSiblingValues() is called, which calls traceSiblingValue(). It traces in several iterations strangely back to the same register (inside a loop), finds it marked to be spilled, and the spill is cancelled: Inline spilling %vreg86 [1396r,2276r:0) 0 at 1396r >From original %vreg76 Tracing value %vreg86:0 at 1396r %vreg86:0 at 1396r: copy of %vreg87:6 at 1168r kill=1 %vreg87:6 at 1168r: copy of %vreg87:5 at 1120B kill=1 %vreg87:5 at 1120B: split phi value, checking 1 phi-defs, and 2 non-phi/orig defs %vreg87:7 at 2276r: copy of %vreg86:0 at 1396r ki...

...ed. In spill(), analyzeSiblingValues() is called, which calls traceSiblingValue(). It traces in several iterations strangely back to the same register (inside a loop), finds it marked to be spilled, and the spill is cancelled: Inline spilling %vreg86 [1396r,2276r:0) 0 at 1396r >From original %vreg76 Tracing value %vreg86:0 at 1396r %vreg86:0 at 1396r: copy of %vreg87:6 at 1168r kill=1 %vreg87:6 at 1168r: copy of %vreg87:5 at 1120B kill=1 %vreg87:5 at 1120B: split phi value, checking 1 phi-defs, and 2 non-phi/orig defs %vreg87:7 at 2276r: copy of %vreg86:0 at 1396r ki...

...nt-after-all and -debug output starting with the coalescer pass. The verification failure is right after the first pass of MachineCopyPropagation which runs after the greedy allocator. > 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? Sorry, I should have pointed this out before: because the loop over instructions in MachineCopyPropagation is only visiting the BUNDLE instructions themselves (i.e. it does not visit the instructions inside the BU...

...eg. The problem is that if vreg87:5, i.e., the original phi, is not the original value then it must have been inserted by splitting. Based on what you said this is not the case, so we end up in this weird situation. If you cannot share the debug output, you could check the following for me: 1. how vreg76 gets split? 2. what is the second non-phi/defs for vreg87:5? 3. if vreg87:5 is not inserted by splitting, how does it gets here? Thanks, -Quentin On Nov 21, 2014, at 9:22 AM, Jonas Paulsson <jonas.paulsson at ericsson.com<mailto:jonas.paulsson at ericsson.com>> wrote: Hi Quentin,...

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 interval *** - function: utils_la_suite_matmul_ref - interval: %vreg77

...The copy propagation seemed to be working on vregs. This was extra confusing as D30751 seems to be currently reverted from trunk so I couldn't find references to that code. > >> 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? > > Sorry, I should have pointed this out before: because the loop over instructions in MachineCopyPropagation is only visiting the BUNDLE instructions themselves (i.e. it does not visit the instructions inside...

...i.e., the original phi, is not the original value then it must have been inserted by splitting. >> Based on what you said this is not the case, so we end up in this weird situation. >> >> If you cannot share the debug output, you could check the following for me: >> 1. how vreg76 gets split? >> 2. what is the second non-phi/defs for vreg87:5? >> 3. if vreg87:5 is not inserted by splitting, how does it gets here? >> >> Thanks, >> -Quentin >> >> >> On Nov 21, 2014, at 9:22 AM, Jonas Paulsson <jonas.paulsson at ericsson....