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: "Richard Earnshaw (lists)" <Richard dot Earnshaw at arm dot com>
- To: Torsten Duwe <duwe at suse dot de>
- 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 13:35:52 +0000
- 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> <20170301133217.GC730@suse.de>
On 01/03/17 13:32, Torsten Duwe wrote:
> 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?
>
I haven't reviewed it yet. I'm not really planning to spend any more
time on this until stage1 re-opens.
R.
> Names better than -fpatchable-function-entry anyone?
>
> Torsten
>