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

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>

> 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.
While exposing this would be conceptually OK, how would we implement
it? Take pre_ual_syntax for example. With "-c -integrated-as" we know
the answer is currently no since we don't implement it. But what about
"-no-integrated-as -S"? We have no idea where that assembly is going.
It might be sent to gas (has it) or back to us (doesn't have it) or
the ARM assembler (I don't thin it has it).

Cheers,
Rafael

On 25 February 2014 12:33, Rafael Espíndola <rafael.espindola at
gmail.com> wrote:
> While exposing this would be conceptually OK, how would we implement
> it? Take pre_ual_syntax for example. With "-c -integrated-as" we
know
> the answer is currently no since we don't implement it. But what about
> "-no-integrated-as -S"? We have no idea where that assembly is
going.
> It might be sent to gas (has it) or back to us (doesn't have it) or
> the ARM assembler (I don't thin it has it).
This is a very good point. Such macros *only* make sense if you're
actually using the assembler to assemble files, not just validate a
piece of assembler that will be passed, as is, to another assembler,
which might not recognize the syntax that you do.

If the decision is in the compiler, than the compiler either knows
*exactly* what the assembler can or cannot deal with (we don't), or it
just doesn't make sense.

cheers,
--renato