https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326
--- Comment #22 from luoxhu at gcc dot gnu.org ---
https://gcc.gnu.org/pipermail/gcc/2020-December/234474.html
So this issue seems invalid since "fabs(x)*y+z” or "fabs(x)+y+z"(x,y,z are
float) could result in -+Inf sometimes, while it won't getti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326
--- Comment #21 from rguenther at suse dot de ---
On December 11, 2020 6:51:05 PM GMT+01:00, "segher at gcc dot gnu.org"
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326
>
>--- Comment #20 from Segher Boessenkool ---
>Yes, that is cle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326
--- Comment #20 from Segher Boessenkool ---
Yes, that is clear... But we have ***double*** x in that example even,
as the declared type of the parameter, so converting that to float is
almost certainly a bad idea?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326
--- Comment #19 from Richard Biener ---
(In reply to Segher Boessenkool from comment #18)
> Why is it correct to convert the double x to single precision here?!
For
float foo(float f, float x, float y) {
return (fabs(f)*x+y);
}
it is not unles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326
--- Comment #18 from Segher Boessenkool ---
Why is it correct to convert the double x to single precision here?!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326
--- Comment #17 from luoxhu at gcc dot gnu.org ---
(In reply to rsand...@gcc.gnu.org from comment #16)
> > 2) mad2.c
> >
> > float foo (double x, float y, float z)
> > {
> >return ( y * fabs (x) + z );
> > }
> >
> >
> > mad2.c.098t.cunrol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326
--- Comment #16 from rsandifo at gcc dot gnu.org
---
> 2) mad2.c
>
> float foo (double x, float y, float z)
> {
>return ( y * fabs (x) + z );
> }
>
>
> mad2.c.098t.cunrolli:
>
> foo (double x, float y, float z)
> {
> double _1;
> d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326
--- Comment #15 from rguenther at suse dot de ---
On Fri, 27 Nov 2020, luoxhu at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326
>
> --- Comment #14 from luoxhu at gcc dot gnu.org ---
> (In reply to luoxhu from comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326
--- Comment #14 from luoxhu at gcc dot gnu.org ---
(In reply to luoxhu from comment #13)
>
> 2) mad2.c
>
> float foo (double x, float y, float z)
> {
>return ( y * fabs (x) + z );
> }
>
>
> mad2.c.098t.cunrolli:
>
> foo (double x, float
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326
--- Comment #13 from luoxhu at gcc dot gnu.org ---
Tried implementation with backprop, found that this model seems not suitable
for double promotion remove with BACK propagation. i.e:
1) mad1.c
float foo (float x, float y, float z)
{
return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326
--- Comment #12 from rsandifo at gcc dot gnu.org
---
(In reply to rguent...@suse.de from comment #11)
> The larger expressions should be subject to a propagation pass and not
> arbitrarily complex static pattern matching. Maybe backprop is a su
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326
--- Comment #11 from rguenther at suse dot de ---
On Mon, 23 Nov 2020, luoxhu at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326
>
> --- Comment #10 from luoxhu at gcc dot gnu.org ---
> Even we could optimize fabs to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326
--- Comment #10 from luoxhu at gcc dot gnu.org ---
Even we could optimize fabs to fabsf, it doesn't help here as y and z are
already promoted to double, then we still need a large pattern to match the
MUL&PLUS expression in match.pd, so fabs to fa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326
--- Comment #9 from luoxhu at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #6)
> (In reply to luoxhu from comment #4)
> > float foo(float f, float x, float y) {
> > return (fabs(f)*x+y);
> > }
> >
> > the input of fabs is float typ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326
--- Comment #7 from joseph at codesourcery dot com ---
I agree that match.pd is a sensible place for this (and the front end is
not, we should be getting optimizations out of the front ends).
I'd encourage anyone looking at this also to look at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326
--- Comment #6 from Andrew Pinski ---
(In reply to luoxhu from comment #4)
> float foo(float f, float x, float y) {
> return (fabs(f)*x+y);
> }
>
> the input of fabs is float type, so use fabsf is enough here, drafted a
> patch to avoid double p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326
--- Comment #5 from luoxhu at gcc dot gnu.org ---
With above hack, changing argument x from float to double could still generate
correct code with conversion of fabsf result:
float foo(float f, double x, float y) {
return (fabs(f)*x+y);
}
006t.g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326
luoxhu at gcc dot gnu.org changed:
What|Removed |Added
CC||luoxhu at gcc dot gnu.org,
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-07-09 06:08 ---
Related to PR 32685.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDepend
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-21 06:08 ---
I think to fix this one, we need a real pass to remove the promotions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-12
20:26 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
E
22 matches
Mail list logo
