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

This seems to be a slightly contentious suggestion, so it seems fitting to
bring it up on cfe-dev.

Given that -fintegrated-as and -fno-integrated-as are available to the
user, and that the integrated assembler can be a bit stringent (as compared
to GAS at least, which, for example, supports deprecated syntax), it might
be nice to permit the user to detect that an integrated assembler is in use.

The flag is intentionally generic so that if another compiler were to
implement an integrated assembler, the same flag could be used.  The
variant could be detected similar to how the compiler is detected (e.g.
defined(__clang__) && defined(__INTEGRATED_ASSEMBLER__) would indicate
the
LLVM IAS).

This would allow for also checking the version of the assembler which is
currently not possible.  Doing would enable using newer features of the
assembler over time, while not breaking compatibility will slightly older
toolchains.

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

As mentioned on IRC, I am opposed to the idea. There are few reasons why:

* The integrated assembler is just another assembler. I would't like
for us to provide a compile time macro for it but not for the version
of gas for example.
* The only cases we should be incompatible are when some feature is
completely missing in one of the assemblers.

Do you have an specific use case in mind? I.E, an example source that
would use __INTEGRATED_ASSEMBLER__? Is that a case that is not
considered a bug (including missing features) in MC?

Cheers,
Rafael

On 24 February 2014 00:11, Saleem Abdulrasool <compnerd at compnerd.org>
wrote:
> The flag is intentionally generic so that if another compiler were to
> implement an integrated assembler, the same flag could be used.  The
variant
> could be detected similar to how the compiler is detected (e.g.
> defined(__clang__) && defined(__INTEGRATED_ASSEMBLER__) would
indicate the
> LLVM IAS).
As I said over IRC, I'm also completely against it.

First of all, __INTEGRATED_ASSEMBLER__ would mean any integrated
assembler, not only LLVM's, even though it was created here, other
tools will compile the same code and could mess up with developers'
heads. If anything, it should be called __LLVM_IAS__ (as Joerg
suggested).

Now, on to the semantics of such a flag...

This flag would separate IAS vs. !IAS, which in itself is a pretty bad
separation of things. Even though it *can* be used to mean "I'm using
a modern assembler", It would actually be primarily used to write code
that is only relevant (or supported) but our integrated assembler.
This would create a whole class of ifdefs that would only work with
our assembler. Moreover, the fact that we assume our assembler is
"modern", means that nothing else will appear in a decade or so better
than LLVM, which in my view, is a pretty limited view of the world. I
can't see how that is *NOT* going to be yet another magic block of ASM
that only one tool supports.

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.

There is legacy code that is complicated to compile without some form
of backward compatibility, I know that, but I'd rather do like Iain
said and have an assembler with multiple personality (that can support
multiple syntaxes separately) than start adding magic macros. To me,
it seems like the wrong hack to be fixing the wrong problem.

As I said before, the worse the hack, the longer it lingers.

cheers,
--renato

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>