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? :)
