This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFA:] Fix gcc.c-torture/execute/20020720-1.x and further analysis
- From: Roger Sayle <roger at eyesopen dot com>
- To: John David Anglin <dave at hiauly1 dot hia dot nrc dot ca>
- Cc: <gcc-patches at gcc dot gnu dot org>
- Date: Sun, 1 Sep 2002 21:22:40 -0600 (MDT)
- Subject: Re: [RFA:] Fix gcc.c-torture/execute/20020720-1.x and further analysis
> One possible fix, would be to iterate over REG_EQUAL notes
> in try_combine, but I fear that would significantly slow
> the compiler.
>
> The other possibility is to avoid having (reg:DF 69) placed
> in memory at all. This is a constant value provided as a
> floating point argument to a function that gets inlined.
> If this parameter could be provided to the inlined routine
> in a register, or via a constant pool, combine could do the
> right thing.
I've just remembered, there's also a third alternative. Adding
condition code loading patterns to the PA-RISC backend. Allowing
(set (reg:CCFP 0) (const_int 0)) to be recognized [and a similar
pattern for (const_int 1)] provides a convenient place holder
for GCC's optimization passes. In over 99% of cases, the user
of the condition code will then be simplified, and the original
condition code setting insn should be eliminated.
I'm not a backend expert. Are condition code loading patterns
considered "good style" in GCC's machine descriptions?
Roger
--