[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130827091730.GN20515@brightrain.aerifal.cx>
Date: Tue, 27 Aug 2013 05:17:30 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: Optimized C memset
On Tue, Aug 27, 2013 at 10:52:55AM +0200, Jens Gustedt wrote:
> Hello,
>
> Am Dienstag, den 27.08.2013, 04:30 -0400 schrieb Rich Felker:
> > One aspect of this code that may appear ugly at first is the usage of
> > the __GNUC__ macro.
>
> It not only *appears* to be ugly :)
>
> You already have a slight inconsistency in that at one point the code
> depends on a particular version of "gcc" and other part only depends
> on the fact that the __GNUC__ macro is set.
That's intentional. The __may_alias__ attribute has existed since GCC
3.2 (I did the research just a little bit ago). Earlier versions of
GCC certainly aren't capable of making optimization that could see
cross-translation-unit aliasing, so it's "safe" to do without the
attribute on such versions.
> There are a lot of compilers out there faking to be a gcc of some
> version and that are not always feature consistent with the gcc
> version that they are claming to fake. ICC is notorious for that. So
> to my opinion this is a dangerous path to follow. (I don't know about
> any problems with the __may_alias__ attribute, though)
So far, my experience is that compilers which advertise themseleves as
"GNU C" compilers have all the semantic features of GCC 3 at the very
least. Is this an invalid assumption?
Note that even if we "wrongly" detect a compiler as supporting
__may_alias__, as long as it doesn't give errors on unknown GCC
attributes, the situation is no worse than what we have right now:
aliasing violations that the compiler can't see without performing
cross-translation-unit analysis. So the code couldn't break without a
very fancy compiler, and I would expect any compiler providing such
fancy optimization and claiming it's "GNU C" to support the GNU C
feature for allowing aliasing in certain places.
> To make this easier to maintain, I'd suggest to introduce a special
> feature test macro, something like __has_may_alias__, and have that
> set at the beginning of the file in a section that is clearly
> dedicated to compile time feature detection. Other compilers may have
> different syntax for such a feature (a _Pragma comes in mind) and may
> be detected quite differently than by gcc version numbering.
Where would you suggest it be added? The result of the check is only
used in one place, so I don't see how
#if ....
#define __has_may_alias__
#endif
#ifdef __has_may_alias__
[use it]
#endif
is better than just
#if ....
[use it]
#endif
in any practical sense.
If on the other hand you're suggesting that I should be more
conservative and check not just for __GNUC__, but also for the
availability of __may_alias__, in the actual code body (rather than
just the typedefs), then it may make more sense.
> Such specific feature test macros is the way that clang goes, and from
> my experience this is much easier to maintain and to understand when
> you stumble on such #ifdef'ed code. You not only know that this needs
> a special version of a compiler, but also for what reason.
Oh, I agree it's much cleaner. Sadly, though, GCC doesn't seem to give
us that information...
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.
