https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113779
Hans-Peter Nilsson changed:
What|Removed |Added
CC||hp at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113779
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113779
--- Comment #5 from Miro Kropacek ---
I have been told that one of the reasons why post-incrementing modes are not
supported / preferred these days is that they halt the CPU pipeline (of course,
totally not applicable on m68k). So with the offse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113779
--- Comment #4 from Mikael Pettersson ---
I'm not sure this is an m68k bug. I tried several targets that have
auto-increment addressing modes (m68k, pdp11, msp430, vax, aarch64) and none of
them would use auto-increment for this test case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113779
--- Comment #3 from Miro Kropacek ---
> I wonder if the code we emit is measurably slower though? It's possibly
a little bit larger due to the two IV increments.
It's definitely slower as both offsets next to the An registers generate a
separa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113779
--- Comment #2 from Richard Biener ---
I don't think IVOPTs would use postinc for the intermediate increments. It's
constant propagation/forwarding that accumulates the increments to a constant
offset which removes dependences on the instructio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113779
--- Comment #1 from Andrew Pinski ---
> So what's the catch here? Why gcc hates move.l (ax)+,(ay)+ so much?
At one point of time (before I think GCC 9 or 8 or so), GCC's IV-OPTs
optimization does not take into account post/pre increment, but no
