llvm dev - Feb 2014 - [LLVMdev] RFC: Adding __INTEGRATED_ASSEMLER__ macro

First, I would assume this would be better spelled as:

__has_feature(integrated_assembler)

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140223/9460540b/attachment.html>

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>

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>

On 25 Feb 2014, at 03:29, Saleem Abdulrasool <compnerd at compnerd.org>
wrote:
> 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.
Because the size of long long doesn't change between versions.  If I have
code that requires long long to be 128 bits now, it won't suddenly work
later on a platform where it's 64 bits just because I upgrade my compiler.

The test you want is not 'is the assembler the LLVM integrated
assembler', it's 'does the assembler support pre-UAL syntax'. 
If LLVM 3.9 implements support for pre-UAL syntax, then your test would be wrong
and you've added a dependency on an external assembler for no reason.

The problem with exposing these as preprocessor macros at all is that, while
it's easy for clang to know about the features of the LLVM integrated
assembler, it has no knowledge at all of the behaviour of whatever tool it finds
called as, other than that it accepts gas-compatible arguments.  The only way
for it to find out would be to interrogate the assembler on startup.

If you depend on a particular feature like this, your best bet is to encode the
logic in your build configuration system: try to compile a simple file
containing pre-UAL syntax assembly and see if it works.  You'll need to
encode the fall-back logic in your build system anyway.

David