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>
Saleem Abdulrasool
2014-Feb-25 03:29 UTC
[LLVMdev] RFC: Adding __INTEGRATED_ASSEMLER__ macro
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>
Chandler Carruth
2014-Feb-25 03:39 UTC
[LLVMdev] 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>
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