RE: [PATCH] splits after reload

["Rakesh Kumar - Software, Noida" <rakeshku at noida dot hcltech dot com>]

> -----Original Message-----
> From: Richard Henderson [mailto:rth@redhat.com]
> Sent: Wednesday, February 04, 2004 3:00 PM
> To: Rakesh Kumar - Software, Noida
> Cc: gcc-patches@gcc.gnu.org; Joern Rennecke
> Subject: Re: [PATCH] splits after reload
> 
> 
> On Wed, Feb 04, 2004 at 02:50:21PM +0530, Rakesh Kumar - 
> Software, Noida wrote:
> > I'd like to advocate defining the target hook for
> > recombining splits in split_all_insns ().
> 
> No.  Absolutely not.  This is not the purpose of split_all_insns.
> 
> It kinda sounds like you want reload-cse to run later than it
> currently does.  That might be a quite reasonable solution, but
> it would certainly have to be tested on many targets.
> 

No, that won't serve the purpose. reload_cse won't be able to
recognize the patterns I'm trying to recombine. Consider some
target splitting a complex insn into simpler insns. These 
simpler insns can be recombined as soon as the split happens.
In case of SH, a DFmode load/store insn is split into three insns
after reload. For example

fmov.d @r1, dr2	/* a 64-bit load.  */

This insn is split into

fmov.s @r1+, fr3	/* 32-bit load.  */
fmov.s @r1, fr2
add #-4, r1		/* Address arithmetic insn.  */

The problem is with the 3rd insn generated. There are a number of
cases where it can be combined with other ADD insns in the same
basic block (as evident from the size gains). It can help
eliminate similar problems on other targets as well. There is a
hoard of arithmetic operations like ADD, OR, XOR,
SHIFT, SUB, etc. which are possible candidates.

Targets generates the complex insns initially and later splits them
to simpler ones. But this approach suffers from side effects.
The combiner pass runs even before the splitter runs for the
very first time. GCC doesn't get the opportunity for combining
the insns those would be generated after combiner pass.
Almost every optimization is repeated after reload (be it CSE,
GCSE, or Scheduler). But combiner misses its share.

An alternative pass, peephole2 comes for rescue. But it certainly
is not the substitute for combiner accounting to its limitations.
Particulary, it requires window size to be limited.
There is no way I could run a peephole on whole basic block.

I understand that re-running combiner pass would be an overkill and
certainly
not favoring the idea. But the problem can't be denied. Here's
an alternative mechanism that lets the targets decide action after split.

Thanks for looking at the patch.

Regards,
Rakesh Kumar