Hi all, I remember the discussion about promoting the integrated ARM assembler as the default option, but I don't remember the outcome. While compiling on ARM, I noticed that clang is not setting the integrated-as by default and is calling GAS before LD, which sometimes cause confusion (GAS doesn't like using r13 as a GPR, for instance). While this is unpredictable in Thumb, it's still allowed in ARM mode (though frowned upon). But aside from discussing the SP issue, is there anything holding the integrated assembler back from being on by default? cheers, --renato -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130205/5f32c81e/attachment.html>
Hi Renato,> is there anything holding the integrated assembler back from being on bydefault? For ARM-ELF, a couple missing pieces I see: 1) The assembly parser does not parse the ARM-ELF directives. 2) The Exception Handling ABI does not appear to be supported. Try this: $ echo "void a(){}" | clang -target arm-none-linux-gnueabi -mllvm -arm-enable-ehabi -integrated-as -c -xc - Not implemented yet <stack dump> 3) There are -Wa options that the integrated assembler does not recognize. To reproduce these issues, try building chromium targeting Android with "clang=1" after adding '-integrated-as' to cflags in "build/common.gypi". http://code.google.com/p/chromium/wiki/Clang -Greg On Tue, Feb 5, 2013 at 6:27 AM, Renato Golin <renato.golin at linaro.org>wrote:> Hi all, > > I remember the discussion about promoting the integrated ARM assembler as > the default option, but I don't remember the outcome. > > While compiling on ARM, I noticed that clang is not setting the > integrated-as by default and is calling GAS before LD, which sometimes > cause confusion (GAS doesn't like using r13 as a GPR, for instance). > > While this is unpredictable in Thumb, it's still allowed in ARM mode > (though frowned upon). But aside from discussing the SP issue, is there > anything holding the integrated assembler back from being on by default? > > cheers, > --renato > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130205/5ff31ee1/attachment.html>
Hi Greg, 1) The assembly parser does not parse the ARM-ELF directives.>Is this for inline asm?> 2) The Exception Handling ABI does not appear to be supported. >AFAIK, this is not exclusive to the integrated assembler. EHABI doesn't work properly with anything. Even the ASM tables generated don't make sense on slightly more complicated cases. But I haven't tested recently to know.> Try this: > $ echo "void a(){}" | clang -target arm-none-linux-gnueabi -mllvm > -arm-enable-ehabi -integrated-as -c -xc - > Not implemented yet >Seems to work for me... ;) 3) There are -Wa options that the integrated assembler does not recognize.>That's not really a problem and will *always* be that way. It doesn't make sense for Clang/LLVM to implement every GCC flag as soon as GCC supports it. I can see a few issues, but none that wouldn't make sense to turn it upside down and require -no-integrated-as when the user needs special features from GAS... Otherwise, it's likely that it'll never be good enough to be enabled by default and issues will never be fixed on it... :/ cheers, --renato -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130205/672ba065/attachment.html>
Hi Greg, I'd also like to see the integrated assembler enabled, though I'm only very weakly connected to the 32-bit backend.> 1) The assembly parser does not parse the ARM-ELF directives.Renato asked about inline assembly here, but I think the key question is over the directives LLVM itself decides to generate as a result of Clang invocations. I had a very brief encounter last year which suggested this path was in place. Is there anything you're aware of that's missing along that route? If there is, I think there's a good chance we can invest some time in fixing it. In general terms, I'd like to see integrated-as enabled as soon as it reasonably can be. Relying on gas is icky. Does anyone know of actual clang regressions that would be triggered? Cheers. Tim