This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [rfc] subreg lowering pass / Overcoming double-set difficulties for CC re-use


You wrote Sonntag, 11. Juni 2006 13:06 :
> On Sunday 11 June 2006 13:01, BjÃrn Haase wrote:
> > Putting all together, one would be replacing the present pass sequence
> >
> >   ...
> >   NEXT_PASS (pass_combine);
> >   NEXT_PASS (pass_if_after_combine);
> >   NEXT_PASS (pass_partition_blocks);
> >   NEXT_PASS (pass_regmove);
> >   NEXT_PASS (pass_split_all_insns);
> >   ...
> >
> > by
> >
> >   ...
> >   NEXT_PASS (pass_combine);
> >   NEXT_PASS (pass_if_after_combine);
> >   NEXT_PASS (pass_partition_blocks);
> >   NEXT_PASS (pass_regmove);
> >   NEXT_PASS (pass_use_split_for_exposing_CC_complexity);
> >   NEXT_PASS (pass_cse3);
> >   NEXT_PASS (pass_use_split_for_again_hiding_CC_complexity_and_possibly
> > smashing_subregs);
> >   if (target_uses_subreg_lowering)
> >     {
> >       NEXT_PASS (pass_subreg_lowering_according_to_rth);
> >       NEXT_PASS (pass_cse4);
> >     }
> >    ...
>
> Tearing it all apart, one would need to do something with CSE to make
> it less slow before a pass_cse3 and pass_cse4 should even be considered.
I completely understand your concerns about compile-time. There's a difference 
between planning to build a 32 kByte executable for a uC or a large linux 
distribution. The uC folks are probably much much more concerned about code 
size than compile time :-).

My objective just was just to find the easiest way to get rid of cc0 for the 
AVR without falling behind what we are having right now.

Maybe concerning the pass sequence, there is no real "one size fits it all". 
With my present working version of the AVR port, I am having so much 
different RTL after splitting so that I am convinced that re-running at least 
CSE would be a big advantage. This will be quite different for the targets 
originally supporting 32 bit operations. Maybe one solution could be to use 
target defines in order to selectively enable passes that could be expected 
to be justified only for a subset of the targets.?

Probably the best way to proceed with discussing the issue would be that I 
first finish the modified CCmode avr target. I could then analyze the effect 
of additional RTL passes and post the results here. If it really comes out 
that considerable improvements could be realized, you will certainly 
understand if I'd be going to ask for the possibility of re-running some RTL 
passes after split for the AVR-type target family :-).

Bjoern.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]