Re: [rfc] multi-word subreg lowering pass

[Daniel Jacobowitz <drow at false dot org>]

On Sun, May 28, 2006 at 09:52:32AM -0600, Roger Sayle wrote:
> 
> On Sun, 28 May 2006, [utf-8] Björn Haase wrote:
> > In order to motivate the more skilled gcc folks to consider above
> > issue: Maybe what comes out could also prove to be helpful for future
> > improvements of 64 bit arithmetics on 32 bit hosts?
> 
> Hi Bjoern (and Richard),
> 
> I just thought I'd mention that I've been investigating variants
> of RTH's subreg lowering patch myself.  However, rather than perform
> this as a late RTL pass, I've been trying out variants that do the
> lowering at RTL expansion time.  The mechanism is for the backend to
> specify CONCAT_MODE_P(mode) for integer modes, meaning that it would
> like operations in this mode to be represented as operations on a
> pair of registers in a narrower mode.  This then resues the existing
> expansion-time CONCAT mechanism for tracking pseudo pairs, and debug
> information.

Hi Roger,

I haven't spent much time at all thinking about this issue, so don't
take it too seriously.  But, I wonder if this is so early that it might
penalize some other situations...

For x86, particularly for arithmetic (as opposed to just store and
load), the situation is clear-cut.  You have only 32-bit registers to
work with.  But for some other targets, you have both 32-bit and 64-bit
registers.  One example that I'm familiar with is ARM iWMMXt.  It has
the standard ARM 32-bit registers, and some 64-bit coprocessor
registers.  The coprocessor registers are, in some cases, expensive to
use - you have to transfer values into and out of the coprocessor
fairly explicitly.  But there are some 64-bit operations that are much
faster in the coprocessor.

If a value is worth loading into the coprocessor, then it should be
treated as 64-bit.  If it's not, though, it would be wonderful to split
it and handle the two halves separately.  Will splitting 64-bit values
at expand time make it hard to use 64-bit registers for them later?

Don't read too much into what the current GCC does with the WMMX
registers, by the way - that code needs some attention and updating, it
hasn't been touched since e.g. before autovectorization, and I think a
lot of the cost estimates are off now.

-- 
Daniel Jacobowitz
CodeSourcery