Re: Reload fix to handle unarry operators in operands correctly V2

[Jan Hubicka <hubicka at atrey dot karlin dot mff dot cuni dot cz>]

> > This is my second approach to solve the SECONDARY_MEMORY_NEEDED and unary
> > operators matched in operands problem.
> 
> I have to admit I didn't follow your patches closely (there are too many :-).
(and there will be even more soon :)
> Can you describe again (or point me to an archived message that describes)
> what you are trying to achieve here?
The message is http://gcc.gnu.org/ml/gcc-patches/2000-01/msg00136.html

The problem is that I am using predicates to accept float_extend in the
operands of fp instructions because these are no-ops on i387 and
otherwise they cause bad results in register allocation, scheduler etc...

originally the i386.md used approach that had many patterns for
most of possible combinations of operations and float_extend operands
(and there are many of them).

The problem I am running into is that reload may require secondary memory
(such as:

(plus:DF (float_extend:DF (REG:SF %eax) (REG:DF %st(0))

and reload currently misses this and emits nonexistent float_extend instruction.

Note that I am not sure how many ports currently use such tricks with unary
operators in the operands (Jeff noted that there are some), but maybe whole
concept is somewhat kludge and we may return to the original approach and
possibly write some script to generate all those numberous patterns in i386.md
file automatically, if this turns out to be inacceptable.

Also note that big disadvantage of this second approach is, that it makes
almost impossible to turn float_truncate into similar noop later (due to
explosion of patterns).
I believe that at least under -ffast-math the float_extends may be no-ops.

Honza
> 
> Bernd