Re: Analysis of high priority PR c/2454

[Roger Sayle <roger at eyesopen dot com>]

On Sun, 30 Jun 2002, Alan Modra wrote:
> On Sat, Jun 29, 2002 at 12:08:32PM -0600, Roger Sayle wrote:
> > The issue is that combine merges the two instructions together and
> > calls simplify_shift_const on the following:
> >
> >     (ashiftrt:SI (ashift:SI (subreg:SI (reg:QI 46) 0)
> >                             (const_int 24 [0x18]))
> >                  (const_int 24 [0x18]))
> >
> > which it manages to reduce to just the paradoxical subreg:
> >
> >     (subreg:SI (reg:QI 46))
>
> Smells a bit like PR 5169.

Thanks for the pointer.  Indeed, thanks to your analysis, the
PA-RISC problem is caused by simplify_shift_const reducing

    (lshiftrt:SI (ashift:SI (subreg:SI (reg:QI 46) 0)
                            (const_int 24 [0x18]))
                 (const_int 24 [0x18]))

(which is a zero extend) to the equivalent:

    (subreg:SI (reg:QI 46))

because the PA-RISC backend defines WORD_REGISTER_OPERATIONS
and LOAD_EXTEND_OP as always ZERO_EXTEND.  This is a symmetric
case to PR c/2454 with zero extension instead of sign extension.


I believe that the correct fix is to remove the LOAD_EXTEND_OP
tests from nonzero_bits and num_sign_bit_copies because although
load instructions appropriately extend their operands, the resulting
RTL may be used in a non-load insn (for example a comparison in
both the PRs above).  The effect is saying that the top bits of
a paradoxical subreg are unknown for all instructions on all
platforms.

An alternative strategy may be to have these backends implement
zero_extend and sign_extend patterns, that only match their load
operations.  Hence the shifts implementing these instructions
can be optimized away when used to load a register from memory,
but are required for register to register moves, etc...

I'd argue for the correctness patch first, and then let the
affected backends return to their original performance with
follow-up patches to their .md files.

If Richard or Jeff agree with this approach, I'll submit a patch
testing on both v850-sim and hppa2.0w-hp-hpux11.00 that I suspect
with fix numerous other mysterious failures.

Roger
--
Roger Sayle,                         E-mail: roger@eyesopen.com
OpenEye Scientific Software,         WWW: http://www.eyesopen.com/
Suite 1107, 3600 Cerrillos Road,     Tel: (+1) 505-473-7385
Santa Fe, New Mexico, 87507.         Fax: (+1) 505-473-0833