This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]