[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 27 Aug 2013 11:34:54 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: Optimized C memset
On Tue, Aug 27, 2013 at 05:20:01PM +0200, John Spencer wrote:
> On 08/27/2013 04:21 PM, Rich Felker wrote:
> >One of the things I think our users like about musl versus glibc
> >is that, for the vast majority of the code, you can fully determine
> >what it's doing without reading other implementation-specific files
> >that define magic macros for things you might not understand -- and
> >that you can take the code and drop it into another project without
> >having to find all the implementation-internal headers it depends on.
> >
> >If something needs to be changed about the logic for may_alias, a
> >simple grep -r will find all the source files it's in and makes it
> >easy to change several occurrences. So I tend to think preserving
> >readability and ease of reuse are more important than avoiding
> >duplication, but if others agree with you, I wouldn't be entirely
> >opposed to adding a "string_impl.h" or similar header with some shared
> >preprocessor logic for all of the string functions that might be doing
> >sketchy things with aliasing and alignment. I'd appreciate comments on
> >this matter from others on which way we should go.
>
>
> my feeling is that we should stick to our current policy of minor
> macros being defined in the TUs that use them, making it both
> simpler to read, and faster to compile (less work for the
> preprocessor).
>
> sufficiently complex macros can go to internal headers instead, so
> there's only one spot to be taken care of.
Indeed, while it's tempting to do something like defining "repr32",
"repr64", etc. types (with may_alias attribute) in a common header, I
think it makes the code a lot less clear, and actually more difficult
to maintain if requirements of individual translation units change
(for example some want to use fixed bit sizes, others want to use
system word size).
What may be beneficial, however, is putting the logic for whether
aliasing rule exemptions are possible at all, and the attribute to use
to get them, into a shared header file. However I'm not convinced that
this logic is anymore complex than "#ifdef __GNUC__", so I think for
now I'd like to start off just doing it simple, and possibly switch
later as more string functions are adapted to document their aliasing
to the compiler. I've always found that if factoring out this kind of
logic is beneficial, the right way to factor it emerges while actually
implementing the code rather than by trying to guess ahead of time
what will be best.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
