https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80574
--- Comment #12 from Andrew Pinski ---
Note the original example in comment #0 is now optimized for GCC 14 but only at
the RTL level rather than the gimple level.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80574
--- Comment #11 from CVS Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:6d449531a60b56ed0f4aeb640aa9e46e4ec35208
commit r14-2698-g6d449531a60b56ed0f4aeb640aa9e46e4ec35208
Author: Andrew Pinski
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80574
--- Comment #10 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #9)
> One thing I noticed is that:
> _2 = MAX_EXPR <_6, a3_7(D)>;
> _3 = MAX_EXPR <_2, a3_7(D)>;
>
> Is not optimized at all.
>
> (for minmax (min max)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80574
--- Comment #9 from Andrew Pinski ---
One thing I noticed is that:
_2 = MAX_EXPR <_6, a3_7(D)>;
_3 = MAX_EXPR <_2, a3_7(D)>;
Is not optimized at all.
(for minmax (min max)
(simplify
(minmax:c (minmax:c@2 @0 @1) @0)
@2))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80574
Andrew Pinski changed:
What|Removed |Added
Target Milestone|8.0 |---
--- Comment #8 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80574
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80574
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |8.0
--- Comment #7 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80574
SztfG at yandex dot ru changed:
What|Removed |Added
CC||SztfG at yandex dot ru
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80574
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80574
--- Comment #5 from SztfG at yandex dot ru ---
> He did not claim it was always better...
Ahh, so I need to do some research to figure out, in which cases static inline
function is better, and in which macro is better. It's bad
> Please don't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80574
--- Comment #4 from Marc Glisse ---
(In reply to SztfG from comment #3)
> Georg-Johann Lay, GCC not always do things better if use static inline
> function instead macro.
He did not claim it was always better...
> For example, this code:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80574
--- Comment #3 from SztfG at yandex dot ru ---
Georg-Johann Lay, GCC not always do things better if use static inline function
instead macro. For example, this code:
#include
#define TYPE uint8_t
#define M_XOR(a,b) ((!!a)^(!!b))
#define
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80574
Georg-Johann Lay changed:
What|Removed |Added
CC||gjl at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80574
--- Comment #1 from Marc Glisse ---
With -fdump-tree-original, the signed case looks perfect:
return MAX_EXPR , a1>, a3>,
a2>, a1>;
(which reassoc eventually simplifies)
while in the unsigned case, we fail to recognize the innermost max:
14 matches
Mail list logo
