https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81594
--- Comment #7 from Segher Boessenkool ---
Peepholes catch fewer cases, and it is very hard to write correct peepholes.
The only reason to use peepholes is when the other passes leave some important
optimisation on the table, and you cannot feasi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81594
--- Comment #6 from Michael Meissner ---
If you look at the original patch, it did try to do this optimization. When I
looked at it some time later, the combiner no longer generated the sequence
because it thought it was slower (due to length, e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81594
--- Comment #5 from Segher Boessenkool ---
Hi Mike,
Please explain (in the code!) why we need a peephole here, why we cannot
generate the faster code earlier? Or why we choose not to? Etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81594
Michael Meissner changed:
What|Removed |Added
Attachment #41854|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81594
--- Comment #3 from Michael Meissner ---
I looked at this a little. The proposed patch doesn't generate the expected
code any more (due to setting the length attribute, which makes it look like
the fix generates slower code).
I re-implemented i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81594
--- Comment #2 from Bill Schmidt ---
What's the status of this one?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81594
Michael Meissner changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81594
--- Comment #1 from Michael Meissner ---
Created attachment 41854
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41854&action=edit
Proposed patch to fix the problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81594
Michael Meissner changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
