[LLVMdev] Disable loop unroll pass

[Shuxin Yang]

I omit your following comment in your previous mail. Please ignore my 
previous mail.

 >There are already some internals parameters in loop unroller to drive 
the heuristics. We use -unroll-count to skip unrolling.
 >But someone may want to enable unrolling even if the target says 
otherwise. IMHO, each target could provide internal flags to disable hw 
 >loop building and let the unroller works "normally"


On 11/23/2012 10:20 AM, Shuxin Yang wrote:
> Hi, Ivan:
>
>   Sorry for deviating the topic a bit. As I told you before I'm a LLVM 
> newbie, I cannot
> give you conclusive answer if the proposed interface is ok or not.
>
>   My personal opinion on these two interface is summarized bellow:
>
> - hasZeroCostLoop()
>    pro: it is clearly state the HW support.
>    con: Having zero cost loop doesn't imply the benefit HW loop could 
> achieve.
>            It is not clear as to if HW-loop conflict with unrolling 
> etc. So optimizer
>            has no idea how to use this interface.  If you just call 
> this interface to disable
>            unrolling, that would be overkill on some arch which has HW 
> support, as
>            on such arch HW-loop and unrolling are orthogonal.
>
>  - hasLoopZeroCostTopology(Loop *L, unsigend TripCount)
>       Why trip-count? It can be derived from the loop itself.
>       Which optimizer will call this interface?
>
>
>  I would suggest following interface:
>
>    /// get unrolling factor of given *INNERMOST* loop from HW's 
> perspective.
>    /// Note: this interface is for innermost loop only. Getting the 
> factor
>    /// for unroll-and-jam should call other interface.
>    virtual int getHwUnrollFactor (Loop*, unsigned CurUnrollingFactor) {
>        // by default, no object to the proposed unrolling factor.
>        return CurUnrollingFactor;
>    }
>
>   I think this interface would completely shield "zero-cost-loop" from 
> higher level
> optimizer, and you certainly can achieve whatever you want in your 
> virtual function
> implementation.
>
>    How does this sound to you? Eli?
>
> Thanks
> Shuxin
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On 11/23/2012 02:41 AM, Ivan Llopard wrote:
>> Hi Shuxin,
>>
>> On 23/11/2012 00:17, Shuxin Yang wrote:
>>> Hi, Gang:
>>>
>>>   I don't want to discuss Open64 internal in LLVM mailing list. Let 
>>> us only focus on the design per se.
>>> As your this mail and your previous mail combined give me a 
>>> impression that :
>>>
>>>    The only reason you introduce the specific operator for HW loop 
>>> in Scalar Opt simply  because
>>> you have hard time in figure out the trip count in CodeGen.
>>>
>>>    This might be true for Open64's CodeGen (I don't want to discuss 
>>> this issue on this mailling list), but
>>> in general it is not true for other compilers.
>>
>> In LLVM, IR and machine code (till reg alloc pipeline) are in SSA, 
>> then trip count detection is almost the same on both sides.
>>
>>>
>>>    I'm dubious about "It greatly simplify the design".  The 
>>> downstream passes need to be fully aware
>>> of this new operator, which doesn't make things any simpler.
>>
>> I think we are going off-topic. I'm not proposing new llvm 
>> instructions to introduce hw loop semantics. What I'd like to do is 
>> to find a good interface between the loop unroller and targets to 
>> prevent loop unrolling.
>> hasZeroCostLoop() and hasLoopZeroCostTopology(Loop *L, unsigend 
>> TripCount) has been proposed so far.
>>
>> Ivan
>>
>>>
>>> Thanks
>>> Shuxin
>>>
>>> On 11/22/2012 02:56 PM, Gang Yu wrote:
>>>> Hi shuxin,
>>>>
>>>> Promote while-loop to do-loop is the job of loop induction 
>>>> recognized, not this transformation. The scalar transform for 
>>>> hwloop in optimizer is for that it is a trouble to discriminate 
>>>> trip counting code with the real production code stuff and do the 
>>>> elimination in cg,  we have to write customized code to handle this 
>>>> general stuff in ervey targets. So, we take the help from optimizer 
>>>> DCE,  make the trip count code hidden in emitted whirl, that 
>>>> greatly simply the design, especially interact with cg unroll, you 
>>>> can see the code, we add  validity check functionality , but the 
>>>> code reduced, more stable.
>>>>
>>>> Gang
>>>>
>>>
>>
>