[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