This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Analysis of high priority PR c/2454
- From: Roger Sayle <roger at eyesopen dot com>
- To: Alan Modra <amodra at bigpond dot net dot au>
- Cc: <gcc at gcc dot gnu dot org>
- Date: Mon, 1 Jul 2002 08:29:18 -0600 (MDT)
- Subject: Re: Analysis of high priority PR c/2454
> 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.
Whilst looking through the uses of LOAD_EXTEND_OP, I believe I've
found the real problem, and I'm currently bootstrapping and testing
the fix on several platforms.
The true issue is that LOAD_EXTEND_OP only applies to paradoxical
subreg's whose arguments are MEMs, i.e. those that really require
a load from memory. Most uses of LOAD_EXTEND_OP check for the
MEM, but a few including those in combine.c's num_sign_bit_copies
and nonzero_bits don't. Adding these missing checks, fixes all
five 20011223-1.c failures on v850-elf.
The benefit is that this fix should not adversely affect performance,
still using LOAD_EXTEND_OP where its valid to do so (rather than my
previous suggestion which was just to disable this optimization).
The bad news, therefore, is that this isn't the problem with
PR target/5169. Substituting (zero_extend:SI (mem:QI)) for
(subreg:SI (mem:QI)) is a valid transformation on PA-RISC where
LOAD_EXTEND_OP(QImode) is ZERO_EXTEND. So the problem with 5169,
if it still exists, is elsewhere. This LOAD_EXTEND_OP bug *is*
exhibited on PA, but the example RTL that's in the GNATS entry
shows a subreg of a mem, which isn't a problem.
I'll post a patch to gcc-patches after further testing.
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