[LLVMdev] RFC: Adding __INTEGRATED_ASSEMLER__ macro

[Renato Golin]

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