This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/39423] [4.6/4.7/4.8 Regression] [SH] performance regression: lost mov @(disp,Rn)
- From: "chrbr at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 11 Jul 2012 09:05:03 +0000
- Subject: [Bug target/39423] [4.6/4.7/4.8 Regression] [SH] performance regression: lost mov @(disp,Rn)
- Auto-submitted: auto-generated
- References: <bug-39423-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39423
--- Comment #16 from chrbr at gcc dot gnu.org 2012-07-11 09:05:03 UTC ---
humm I forgot about this case. It works in one of my dev branches, Let me
extract the uncommitted change and send it to gcc-patches.
Cheers
Christian
(In reply to comment #15)
> Created attachment 27754 [details]
> combine pass based patch
>
> A possible combine pass based solution for the problem.
> It fixes the case mentioned in the original description.
>
> I've also briefly checked some CSiBE code size results with this
> patch applied to rev 189338 for '-m4-single -ml -O2 -mpretend-cmove'.
> It hits only a few spots, but if those are buried inside loops, it might
> be a win.
>
> I'm not sure what's the best thing to do if the mov.l displacement
> goes out of range...
>
> Chris, I know it's been a while but any old memories? :)
(In reply to comment #15)
> Created attachment 27754 [details]
> combine pass based patch
>
> A possible combine pass based solution for the problem.
> It fixes the case mentioned in the original description.
>
> I've also briefly checked some CSiBE code size results with this
> patch applied to rev 189338 for '-m4-single -ml -O2 -mpretend-cmove'.
> It hits only a few spots, but if those are buried inside loops, it might
> be a win.
>
> I'm not sure what's the best thing to do if the mov.l displacement
> goes out of range...
>
> Chris, I know it's been a while but any old memories? :)