On 05/31/2017 02:04 PM, Richard Biener wrote: > On Wed, May 31, 2017 at 1:51 PM, Jakub Jelinek <ja...@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? Martin > > Richard. > >> >> Jakub
