[LLVMdev] Disable loop unroll pass

Ivan Llopard ivanllopard at gmail.com
Fri Nov 23 02:41:20 PST 2012


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




More information about the llvm-dev mailing list