[LLVMdev] Disable loop unroll pass

[Shuxin Yang]

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