Revert Sparc and SparcV9 to external assembler. Now that the CPU
handling is corrected, the primary reason for forcing IAS as default is
gone and the remaining issues are still somewhat problematic in common
Would it be possible to elaborate on the remaining issues for the Sparc integrated assembler? I had a look at bugzilla but could not find any references to issues with the integrated assembler for Sparc.
Sorry for bumping this, but hope it would be possible to explain some of the issues you have found with the assembler. I am interested in having a look at these so we can improve the situation.
@joerg Did you find anything wrong with the integrated assembler for Sparc?
For comparison, the current code is
case llvm::Triple::sparc: case llvm::Triple::sparcel: case llvm::Triple::sparcv9: if (getTriple().isOSFreeBSD() || getTriple().isOSOpenBSD() || getTriple().isOSSolaris()) return true; return false;
Linux does not use the integrated assembler by default.
I can find a thread in 2017 about reviving Sparc https://lists.llvm.org/pipermail/llvm-dev/2017-June/114437.html but I believe the status does not get improved.
I was not aware of any reliance on a system assembler within LLVM. My previous understanding was that one of the features of LLVM is to provide assemblers for all of these architectures, which is useful for cross compiling.
Generally, as a downstream consumer of LLVM as a library, I have no use for external assemblers, and only the integrated assembler is useful. So for me, this commit is either irrelevant to my use case, or, possibly harmful.
If no (inline) assembler is involved, you can likely get away with IAS. Just to give two trivial examples that are not handled by IAS right now:
jmp foo 1: add %o7,(foo-1b),%o2
The former should be handled like jmp %g0+foo, the latter currently triggers an assert even.