[cfe-dev] '__has_builtin' and '-mcpu'

[Martin J. O'Riordan via cfe-dev]

Gosh, not the response I was expecting, I just assumed I had missed implementing something.

Thanks for your reply and the useful bug ticket.  For me it's not a big problem, because I can use:

  #if __has_builtin(__builtin_shave_foobar) && defined(__cpuname__)

but had thought it would be neater to just do:

  #if __has_builtin(__builtin_shave_foobar)

Most of my builtins are bindings to discrete exotic instructions that the compiler cannot easily discover, but each chip variant adds or removes new instructions, which is what prompted my question.  The definitions for these which I added into 'tools/clang/lib/CodeGen/CGBuiltin.cpp' does detect that the requested builtin is not available and I return 'nullptr', so the compiler gracefully diagnoses it and it never gets as far as LLVM and lowering.

Thanks again,

	MartinO

-----Original Message-----
From: Renato Golin [mailto:renato.golin at linaro.org] 
Sent: 28 July 2016 14:54
To: Martin J. O'Riordan
Cc: Clang Dev
Subject: Re: [cfe-dev] '__has_builtin' and '-mcpu'

On 28 July 2016 at 14:24, Martin J. O'Riordan via cfe-dev <cfe-dev at lists.llvm.org> wrote:
> But I was thinking that it might be useful for the programmer to test 
> for the existence of the builtin using ‘__has_builtin’, but while this 
> returns true when give the name of any of our builtins, it does so 
> regardless of which CPU variant was selected.

Hi Martin,

A similar problem was reported by Android:

https://llvm.org/bugs/show_bug.cgi?id=28629

and it seems my interpretation of "has_builtin" was wrong, and yours is right (so was Stephen's).

I'll update that bug to reflect this, but this opens a larger Clang question as to what does it mean to "have a builtin".

In that example, __has_builtin returns true, but it's implemented as a library call and only implemented in Compiler-RT, which is an odd combination. That is why I assumed that it meant that Clang "knew about it and how to lower" instead of "knew how to custom lower without library calls".

Given that this is a CPU specific (at least TargetFeature-specific) feature, getting the target's description is sine qua non to get this working, which means call backs into LLVM. But once you got the Subtarget object, "has<FeatureX>" is a simple call. :)

cheers,
--renato