[llvm-commits] [llvm] r161074 - in /llvm/trunk/lib/CodeGen: MachineTraceMetrics.cpp MachineTraceMetrics.h

[Jakob Stoklund Olesen]

On Jul 31, 2012, at 4:47 PM, Andrew Trick <atrick at apple.com> wrote:

> 
> On Jul 31, 2012, at 1:44 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote:
>> +    if (TargetRegisterInfo::isPhysicalRegister(Reg)) {
>> +      HasPhysRegs = true;
>> +      continue;
>> +    }
>> +    // Collect virtual register reads.
>> +    if (!MO->readsReg())
>> +      continue;
>> +    MachineRegisterInfo::def_iterator DefI = MRI->def_begin(Reg);
>> +    DataDep Dep;
>> +    Dep.DefMI = &*DefI;
>> +    Dep.DefOp = DefI.getOperandNo();
>> +    Dep.UseOp = MO.getOperandNo();
>> +    Deps.push_back(Dep);
> 
> The SSA assumption should be explicit. Can we change getVRegDef to return MachineOperand?

No, it's used all over the place, and MachineOperand doesn't know its own number anyway.

It this something you need over in MISched? Otherwise I won't add it to MRI.

>> +    /// Minimum number of cycles from this instruction is issued to the of the
>> +    /// trace, as determined by data dependencies and instruction latencies.
>> +    unsigned Height;
>> +  };
> 
> This requires a different technique of course. It's nice if uses can "push" uses' heights to their SSA defs.

This is the direction I am taking.

> But that requires that the use knows it is in the def's preferred downward trace, which you might not.

Yes, there are multiple opinions about an instruction's height, depending on the trace you're looking at. As I process a trace bottom-up, I keep instruction heights in a map on the side. I only transfer heights to the MTM.Cycles map when I know I'm on the preferred trace.

The temporary height map is dumped to a live-in list for each basic block. It maps reg -> height for all registers required by the block and the trace below it. The live-in list is required for physregs which aren't in SSA form, and it provides a way of computing the critical path length.

> I'm guessing you're just going to walk over all vreg uses filtering those that are in the def's preferred downward trace and recurse on phis.

I am afraid of the performance implications of this approach.

> Things get even more interesting when you try to derive slack (= CricitalPath - Height - Depth) for instructions. It doesn't look like you have enough info yet to estimate cross block dependencies out of the current trace predecessor and into the current trace successor to get the current critical path (or upper bound).

Live-in lists save the day.

I am still working on this bit. It should all work out.

/jakob