[LLVMdev] RFC: Adding __INTEGRATED_ASSEMLER__ macro

Saleem Abdulrasool compnerd at compnerd.org
Mon Feb 24 19:29:08 PST 2014


On Sun, Feb 23, 2014 at 5:18 PM, Chandler Carruth <chandlerc at google.com>wrote:

> First, I would assume this would be better spelled as:
>
> __has_feature(integrated_assembler)
>

Sure, I have no issue with this.


> But I agree with others that "integrated assembler" isn't a feature which
> should be observable in source code.
>
> On Sun, Feb 23, 2014 at 4:27 PM, Renato Golin <renato.golin at linaro.org>wrote:
>
>> On a higher level, there's the quality issue. People should test for
>> *behaviour* and *standards* not *tools* or *versions*. So, if my code
>> only works on ARM UAL syntax, I should ifdef UAL, not ifdef
>> MY_OWN_ASM_VERSION_7.34+. ARM is historically polluted with such
>> flags, and they've now created the ACLE (ARM C Language Extensions),
>> which moves from architecture version to feature support macros and
>> extensions, which means it doesn't really matter what tool you're
>> using, if that tool supports feature A, you can use it.
>>
>
> Very much. If we have specific assembler features, we should expose them
> through __has_feature, but they should be source code visible features
> rather than "my code compiles faster with fewer temporary files" features.
>

Unfortunately, its not that simple.  The IAS is not a perfect drop in
replacement.  As a concrete example, on ARM, the IAS does not support
pre-UAL syntax (which the Linux kernel uses in some cases).  This is more
of a philosophical limitation rather than technical AFAIK.

Having the ability to detect what assembler is being targeted is useful.  I
might be overlooking something, but I dont see why this would be any more
dangerous than exposing the size of long or long long via the preprocessor.

-- 
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140224/cc5879c8/attachment.html>


More information about the llvm-dev mailing list