[LLVMdev] Machine LICM and cheap instructions?

Evan Cheng evan.cheng at apple.com
Fri Jan 9 11:40:33 PST 2015


Some cheap and trivially remateriablizable instructions are free. It makes little sense to hoist them and increase register pressure. In some cases, the register allocator will end up rematerialize them at use sites again.

The heuristics is obviously conservative. Due to phase ordering reasons, register pressure estimates cannot be 100% accurate. It’s here to prevent harm. During my testings from way back then, hoisting these cheap instructions can indeed harm performance. It probably can help in some cases as well. But I’d wager it’s pretty much a wash at best.

Evan

> On Jan 8, 2015, at 1:45 PM, Hal Finkel <hfinkel at anl.gov> wrote:
> 
> Hi everyone,
> 
> The MachineLICM pass has a heuristic such that, even in low-register-pressure situations, it will refuse to hoist "cheap" instructions out of loops. By default, when an itinerary is available, this means that all of the defined operands are available in at most 1 cycle. ARM overrides this, and provides this more-customized definition:
> 
> bool ARMBaseInstrInfo::
> hasLowDefLatency(const InstrItineraryData *ItinData,
>                 const MachineInstr *DefMI, unsigned DefIdx) const {
>  if (!ItinData || ItinData->isEmpty())
>    return false;
> 
>  unsigned DDomain = DefMI->getDesc().TSFlags & ARMII::DomainMask;
>  if (DDomain == ARMII::DomainGeneral) {
>    unsigned DefClass = DefMI->getDesc().getSchedClass();
>    int DefCycle = ItinData->getOperandCycle(DefClass, DefIdx);
>    return (DefCycle != -1 && DefCycle <= 2);
>  }
>  return false;
> }
> 
> So it won't hoist instructions that have defined operands ready in at most two cycles for general-domain instructions. Regardless, I don't understand the logic behind this heuristic. High-register-pressure situations are one thing, but why is it ever profitable in low-register-pressure situations not to hoist even "cheap" instructions out of loop bodies?
> 
> Thanks again,
> Hal
> 
> -- 
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory





More information about the llvm-dev mailing list