This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH v2] Implement no_sanitize function attribute
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Martin Liška <mliska at suse dot cz>
- Cc: Jakub Jelinek <jakub at redhat dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 31 May 2017 15:31:24 +0200
- Subject: Re: [PATCH v2] Implement no_sanitize function attribute
- Authentication-results: sourceware.org; auth=none
- References: <72103b1d-0119-f05d-043d-ca2edf242bf3@suse.cz> <beb96c01-d217-b126-baaa-bcf5682889f4@suse.cz> <20170531083543.GQ24023@tucnak> <83f8580a-03e1-81eb-3216-a1c998810b90@suse.cz> <20170531113321.GT24023@tucnak> <CAFiYyc1G6vsFQiGdreyrf9Vw+E0JuoQYGazXSrENaGzvhy+F=g@mail.gmail.com> <20170531115102.GU24023@tucnak> <CAFiYyc0iFrCCKS152LXzsksE=1ZrOLvWsm=ykX-0=A-SMuHU=w@mail.gmail.com> <878c99de-7ca3-c7c1-ff39-302d5d419fb4@suse.cz>
On Wed, May 31, 2017 at 2:28 PM, Martin Liška <mliska@suse.cz> wrote:
> On 05/31/2017 02:04 PM, Richard Biener wrote:
>> On Wed, May 31, 2017 at 1:51 PM, Jakub Jelinek <jakub@redhat.com> wrote:
>>> On Wed, May 31, 2017 at 01:46:00PM +0200, Richard Biener wrote:
>>>> Just wanting to add that "ab-"using options/variables to implement
>>>> what are really
>>>> function attributes doesn't look very clean. Unless the plan is to get rid of
>>>> function attributes in favor of per-function options.
>>>
>>> Function attribute here is one thing (the way user writes it) and that
>>> combined with the command line options determines the sanitization performed
>>> (the function attributes only say what sanitization flags should be
>>> ignored). The proposed per-function variable is just a cache of this
>>> information, because parsing function attributes every time is way too
>>> expensive.
>>
>> True, but isn't that just an excuse to not improve attribute list
>> representation?
>>
>> Ideally we'd have sth like attributes.def and a sorted vector of
>> integer id, args
>> pairs. Using a sorted vector of the existing stuff (compared to the tree list)
>> might also help.
>
> Then it would be tree-wise very similar to CONSTRUCTOR which also contains vector
> of (index, value) pairs?
>
>>
>> Yes, we'd get (quite?) a bit less attribute list sharing this way but
>> we can still
>> share the actual tree-whatever thing that represents the args.
>
> Any estimation how difficult such transformation would be?
attribute lists are dealt with in quite some places (with or without
helpers) so I guess it would be somewhat invasive but largely
mechanical. Using a .def file vs. the current strings can be
done separately -- after all we can also sort strings. I suspect
doing the string -> ID transform pays off faster (still linear search
but integer comparison instead of string compare).
Richard.
> Martin
>
>>
>> Richard.
>>
>>>
>>> Jakub
>