r191590 - Implements some of the more commonly used intrinsics in Intrin.h

[Chandler Carruth]

Just as a clarifying point for terminology:

Let's define "intrinsic" functions to be a compiler-provided[1] routine (as
opposed RTL provided) which you must #include a header file to use. Thus,
it is a normal interface within the language, not an extension to the
language itself. Then, let's define "builtin" functions to be
compiler-provided routines for which you need not include a header. Thus,
they are built directly into the language. There are a lot of other usages
and definitions we might use, but these seem common in GCC and Clang
communities and express a useful distinction for this discussion, so I
suggest adopting this interpretation.

[1]: Note that there may exist (although at the moment I can't think of
one) intrinsics where the *interface* is provided by the compiler, but the
implementation is transparently provided via some RTL. This is typically
opaque to the user though, so I think it's fair to say they are
compiler-provided -- that is all a user of the routine need worry about.
Those which are unavailable

On Wed, Oct 2, 2013 at 4:46 AM, Timur Iskhodzhanov <timurrrr at google.com>
wrote:
>
> Not yet; we do it in the ASan runtime library though as we want to
> include as few headers as possible in order to avoid implicit
> dependencies from the standard library that might cause bad things
> when you intercept/wrap standard functions in the tool.

Generally speaking, I think it is reasonable for sanitizers to use the
headers shipped with the compiler such as Intrin.h... If needed you could
specifically use them in a freestanding mode. Naturally, you'll want to
watch out for just the situation I mention above with silent RTL
dependencies, but I expect that to be quite rare.
2013/10/1 Warren Hunt <whunt at google.com>:
> Yes, we're not presently supporting the usage model where you can simply
> declare the intrinsics like you would for cl.exe.  We had a pretty
extensive
> discussion about what constitutes a "builtin" versus what constitutes an
> "intrinsic" and the requirements for headers.  Weirdly in MS world you
have
> to declare most "builtins" before you can use them but there are
exceptions
> like __debugbreak().  Ultimately we have an agreement that it would be
nice
> to support the microsoft intrinsics as builtins (i.e. not require the
> header, and potentially not even a definition) but that will take more
work
> plumbing somewhat redundant builtins through clang and it was decided that
> the current approach is both reasonable and expedient.

OK, this looks reasonable.

> Did you find a case in chrome where they are declaring an intrinsic
without including "intrin.h"?

Not yet; we do it in the ASan runtime library though as we want to
include as few headers as possible in order to avoid implicit
dependencies from the standard library that might cause bad things
when you intercept/wrap standard functions in the tool.

> On Tue, Oct 1, 2013 at 6:44 AM, Timur Iskhodzhanov <timurrrr at google.com>
> wrote:
>>
>> Please see the comment at
>> http://llvm.org/bugs/show_bug.cgi?id=13283#c5 for the details.
>>
>> For some reason, the value of *_Addend at the end of the function is
>> wrong if we include <intrin.h>;
>> also, it fails to compile if we declare the function without including
>> the header.
>>
>> 2013/10/1 Warren Hunt <whunt at google.com>:
>> > I've tested them under a variety cases.  Are you concerned about the (-
>> > _Value) clause?
>> >
>> > -Warren
>> >
>> >
>> > On Mon, Sep 30, 2013 at 3:58 AM, Timur Iskhodzhanov
>> > <timurrrr at google.com>
>> > wrote:
>> >>
>> >> 2013/9/28 Warren Hunt <whunt at google.com>:
>> >> > +static __inline__
>> >> >  long __cdecl _InterlockedExchangeAdd(long volatile *_Addend, long
>> >> > _Value);
>> >> > ...
>> >> > +static __inline__ short __attribute__((__always_inline__,
>> >> > __nodebug__))
>> >> > +_InterlockedExchangeAdd16(short volatile *_Addend, short _Value) {
>> >> > +  return __atomic_add_fetch(_Addend, _Value, 0) - _Value;
>> >> > +}
>> >> > +static __inline__ long __attribute__((__always_inline__,
>> >> > __nodebug__))
>> >> > +_InterlockedExchangeAdd(long volatile *_Addend, long _Value) {
>> >> > +  return __atomic_add_fetch(_Addend, _Value, 0) - _Value;
>> >> > +}
>> >>
>> >> Are you sure this is a correct/complete implementation?
>> >> http://llvm.org/bugs/show_bug.cgi?id=13283#c5
>> >
>> >
>
>
_______________________________________________
cfe-commits mailing list
cfe-commits at cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131002/8de00ee3/attachment.html>