https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91425
--- Comment #9 from Andrew Pinski ---
The biggest issue here is that the both ifcombine (and reassociate) and phiopt
does not touch the case where there could be a trapping oeprator to move it and
combine it with a previous operator. This could/s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91425
Andrew Pinski changed:
What|Removed |Added
CC||pinskia at gcc dot gnu.org
Sev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91425
--- Comment #8 from joseph at codesourcery dot com ---
A more general representation would facilitate implementing
__builtin_iseqsig (bug 77928).
(As noted in previous discussions, some processors, e.g. MIPS, actually
have a general comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91425
--- Comment #7 from Marc Glisse ---
(In reply to Segher Boessenkool from comment #6)
> Maybe we should make "is this an ordered comparison" separate from the
> actual comparison code.
I was considering having a single .IFN_FENV_CMP (a, b, opts)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91425
--- Comment #6 from Segher Boessenkool ---
Maybe we should make "is this an ordered comparison" separate from the
actual comparison code.
That would make things quite a bit simpler as well. Maybe we can pull
that through to RTL, as well?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91425
--- Comment #5 from Richard Biener ---
(In reply to Segher Boessenkool from comment #4)
> (In reply to Richard Biener from comment #1)
> > where we end up with
> >
> >[local count: 1073741824]:
> > if (a_3(D) < b_4(D))
> > goto ; [50.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91425
--- Comment #4 from Segher Boessenkool ---
(In reply to Richard Biener from comment #1)
> where we end up with
>
>[local count: 1073741824]:
> if (a_3(D) < b_4(D))
> goto ; [50.00%]
> else
> goto ; [50.00%]
>
>[local count:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91425
--- Comment #3 from Segher Boessenkool ---
There are quite many different cases to test, and many *more* do not currently
generate the wanted code because it isn't optimised properly on gimple level,
and that makes it hard to test the RTL / targe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91425
--- Comment #2 from Marc Glisse ---
I think part of the problem with the current or_comparison optimization is that
it relies on invert_tree_comparison in many cases, and that doesn't really work
for floating point (and we handle the unsafe flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91425
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Status|
10 matches
Mail list logo
