[LLVMdev] RFC: Adding __INTEGRATED_ASSEMLER__ macro

Chandler Carruth chandlerc at google.com
Mon Feb 24 19:39:39 PST 2014


On Mon, Feb 24, 2014 at 7:29 PM, Saleem Abdulrasool
<compnerd at compnerd.org>wrote:

>
>
>> 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.
>

But you've just said: "the IAS does not support pre-UAL syntax". I think
this precisely answers the question. Add
"__has_feature(some_spelling_of_what_UAL_stands_for)" which says
specifically that the UAL syntax is supported. And/or, __has_extension(...)
for the name of the pre-UAL syntax which could hypothetically be supported
as an extension, but isn't in Clang. And/or have the UAL-syntax specify a
name of a preprocessor macro that all conforming compilers that support
this syntax are required to define.

Again, here we have a concrete behavioral feature that we can and should
support testing for. This isn't about whether the assembler is integrated
or not, it is about whether the assembler supports a particular syntax on a
particular platform.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140224/4362d8c9/attachment.html>


More information about the llvm-dev mailing list