This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Initial shrink-wrapping patch
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Bernd Schmidt <bernds at codesourcery dot com>
- Cc: Richard Henderson <rth at redhat dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, richard dot sandiford at linaro dot org
- Date: Thu, 6 Oct 2011 11:27:53 -0700
- Subject: Re: Initial shrink-wrapping patch
- References: <4E5E7342.9050103@codesourcery.com> <g462lcbc22.fsf@richards-thinkpad.stglab.manchester.uk.ibm.com> <4E6E9857.50600@t-online.de> <g4ehzklu0r.fsf@richards-thinkpad.stglab.manchester.uk.ibm.com> <4E6F37D9.9000108@t-online.de> <g4pqj4k702.fsf@richards-thinkpad.stglab.manchester.uk.ibm.com> <4E6F4B90.2050408@codesourcery.com> <g4hb4gk2xa.fsf@richards-thinkpad.stglab.manchester.uk.ibm.com> <4E6F786E.6080407@codesourcery.com> <4E712FD6.5030109@redhat.com> <4E8239ED.9020004@codesourcery.com> <4E85F395.3030006@redhat.com> <4E8B8469.2090605@codesourcery.com>
On Tue, Oct 4, 2011 at 3:10 PM, Bernd Schmidt <bernds@codesourcery.com> wrote:
> On 09/30/11 18:51, Richard Henderson wrote:
>
>> Please do leave out RETURN_ADDR_REGNUM for now. ?If you remember why,
>> then you could bring it back alongside the patch for the ARM backend.
>
> Changed.
>
>> As for the i386 backend changes, not an objection per se, but I'm
>> trying to understand why we need so many copies of patterns.
>
> Also changed.
>
>> I don't see anything glaringly wrong in the middle end. ?Although
>> the thread_prologue_and_epilogue_insns function is now gigantic.
>> If there were an easy way to break that up and reduce the amount
>> of conditional compilation at the same time... that'd be great,
>> but not a requirement.
>
> I don't think there's an easy way; and it's almost certain to break
> stuff again, so I'd rather avoid doing it at the same time as this patch
> if possible.
>
> I can see one possible way of tackling it; have an analysis phase that
> fills up a few basic_block VECs (those which need sibcall returns, those
> which need plain returns, those which need simple returns) and computes
> other information, such as the edges on which prologue and epilogue are
> to be inserted, and then a worker phase (probably split across several
> functions) which does all the fiddling.
>
> Richard S. suggested:
>> ...how about adding a bit to crtl to say whether shrink-wrap occured,
>> and check that instead of flag_shrink_wrap?
>
> Good idea, also changed.
>
> New version below. ?Bootstrapped and tested i686-linux.
>
>
It also caused:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50633
Don't you need to update ix86_expand_prologue?
--
H.J.