Saleem Abdulrasool
2014-Feb-24 00:11 UTC
[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>
Rafael EspĂndola
2014-Feb-24 00:17 UTC
[LLVMdev] RFC: Adding __INTEGRATED_ASSEMLER__ macro
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
Chandler Carruth
2014-Feb-24 01:18 UTC
[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>
Possibly Parallel Threads
- [LLVMdev] RFC: Adding __INTEGRATED_ASSEMLER__ macro
- [LLVMdev] RFC: Adding __INTEGRATED_ASSEMLER__ macro
- Over quota message
- [LLVMdev] Add support for ldr pseudo instruction in ARM integrated assembler
- [LLVMdev] Add support for ldr pseudo instruction in ARM integrated assembler