This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Poll for option name (Was: [PATCH v6] add -fprolog-pad=N,M option)
- From: Torsten Duwe <duwe at suse dot de>
- To: "Richard Earnshaw (lists)" <Richard dot Earnshaw at arm dot com>
- Cc: Sandra Loosemore <sandra at codesourcery dot com>, Marek Polacek <polacek at redhat dot com>, Maxim Kuvyrkov <maxim dot kuvyrkov at linaro dot org>, Bernd Schmidt <bschmidt at redhat dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Szabolcs Nagy <szabolcs dot nagy at arm dot com>, nd at arm dot com, Li Bin <huawei dot libin at huawei dot com>, Jiri Kosina <jkosina at suse dot cz>, Marcus Shawcroft <Marcus dot Shawcroft at arm dot com>, Takahiro Akashi <takahiro dot akashi at linaro dot org>, Andrew Wafaa <Andrew dot Wafaa at arm dot com>
- Date: Wed, 1 Mar 2017 14:32:17 +0100
- Subject: Re: Poll for option name (Was: [PATCH v6] add -fprolog-pad=N,M option)
- Authentication-results: sourceware.org; auth=none
- References: <20161221172333.GA6050@suse.de> <585ACF52.9030004@codesourcery.com> <20170113121953.GA4685@suse.de> <9970dba9-8364-89f7-7a32-a8acd390b7e5@arm.com> <20170215111233.GB13736@redhat.com> <57bdf313-1de8-0d16-3a96-e85d2e9ffec6@arm.com> <20170217165721.GA25613@suse.de> <58A7EA05.4050609@codesourcery.com> <20170301112630.GB730@suse.de> <4474f912-9163-3ff5-8ce7-f75fc11a5c88@arm.com>
On Wed, Mar 01, 2017 at 11:34:37AM +0000, Richard Earnshaw (lists) wrote:
> On 01/03/17 11:26, Torsten Duwe wrote:
> >
> > However, writing some more documentation and being asked for clarity,
> > I found it more depicting to talk about the function entry point than
> > about the prologue. Also, this is about generic instrumentation, and it
> > surely involves NOPs.
> >
> > So, hereby I'd like to start a small poll for a good name for this feature.
> > Anyone with a better idea please speak up now. Otherwise I'll just
> > s/prolog/prologue/g.
>
> Hmm, I'd prefer the bike shed to be green :-)
>
> How about --fpatchable-function-entry=<size-spec>?
>
IMHO qualifies as "better". And green is best anyway :-]
> > I've made another improvement which makes the code even more robust now.
> > +DEF_TARGET_INSN (nop, (void))
> > In gcc/target-insns.def. This way I can easily check whether there is a
> > (define_insn "nop" ...) in the target md. Currently, all CPUs have it, but
> > who knows.
>
> The mid-end already has direct calls to gen_nop with no guards on the
> pattern existing, So the compiler won't build without a NOP pattern.
Richard told me "don't do that", and we found the DEF_TARGET_INSN. So far
I can see gen_nop only in target specifics and in cfgrtl.c -- admittedly
I don't know what that does.
So the v6 code is basically OK?
Names better than -fpatchable-function-entry anyone?
Torsten