Ok, let‘s stop the open64 "polution".
Whether the design is as you stated doesn‘t simpler, the code before
and after the change already tells us.
We take detailed investigation on gcc support for hwloop, then we come
to the conclusion we are essentially the same. So i think the idea can
be shared among different compilers, general abstract tripcount, make
pseudo operators for indentification and special handling, that‘s what
i think might help.
Sent from Huawei Mobile
Shuxin Yang <shuxin.llvm at gmail.com>编写：
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
>
