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