[LLVMdev] Machine LICM and cheap instructions?

[Andrew Trick]

> On Jan 8, 2015, at 3:12 PM, Hal Finkel <hfinkel at anl.gov> wrote:
> 
> ----- Original Message -----
>> From: "Quentin Colombet" <qcolombet at apple.com <mailto:qcolombet at apple.com>>
>> To: "Hal Finkel" <hfinkel at anl.gov <mailto:hfinkel at anl.gov>>
>> Cc: "Dev" <llvmdev at cs.uiuc.edu <mailto:llvmdev at cs.uiuc.edu>>
>> Sent: Thursday, January 8, 2015 5:06:24 PM
>> Subject: Re: [LLVMdev] Machine LICM and cheap instructions?
>> 
>> Hi Hal,
>> 
>> I haven’t looked at the implementation but could it be that we leave
>> room for expensive instructions to be hoisted?
>> The rational being that hoisting a cheap instruction will increase
>> the register pressure and then we may block expensive instruction
>> (assuming we use some kind of iterative algorithm).
> 
> Interesting point. That cuts both ways, however, because hoisting a cheap instruction can then make an expensive instruction loop invariant. Perhaps we need two passes over the instructions to make a good decision here.

Yes, I think up to this point we’ve been heavily reliant on IR-level LICM to handle chains of computation.

It’s kind of hard for me to generalize what’s good/bad in MachineLICM without looking at concrete code for a particular architecture. Maybe the target hook should be more expressive.
-Andy

> 
> Thanks,
> Hal
> 
>> 
>> Other than that, I would say that seem rather silly.
>> 
>> Cheers,
>> Q.
>> 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
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>> 
>> 
> 
> -- 
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>         http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/>
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev <http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150109/05becf66/attachment.html>