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: "John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>
- To: roger at eyesopen dot com (Roger Sayle)
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Mon, 2 Sep 2002 00:34:50 -0400 (EDT)
- 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
As far as I am aware, floating point constants except for zero
have to be loaded from memory.
> > 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.
If I understand correctly, combine would do the right thing if
(reg:DF 69) were copied to another register to be used in the
inlined routine?
> 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.
That sound like a very useful suggestion. The first pattern is
very simple.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)