On 3/17/15 5:35 PM, Steve King wrote:> Clang correctly assembled a .s file when using the -integrated-as > option. Thanks, that is news to me! However, without -integrated-as, > clang invoked 'as', which won't work for a GNU-less target. Accepting > assembler invocation as a good case study for target specific clang > defaults, what is the proper solution?Again, what is the target architecture? (I understand if it's an out-of-tree backend that you can't talk about. If so, I'll stop bugging you about this point.) For some targets, -integrated-as the default is on, for others it defaults to off. It generally depends on how good the integrated assembler is for that target. For example, the default on ARM used to be -no-integrated-as because IAS just wasn't mature enough at the time. The "proper solution" here w.r.t. assemblers is to implement full support for the integrated assembler for the target arch in llvm, and then flip the default for that target. -- Jon Roelofs jonathan at codesourcery.com CodeSourcery / Mentor Embedded
Right, sorry to skip over your question. It is an out-of-tree target I can't be open about. I will start a new thread on the integrated-as problems in my target. On Tue, Mar 17, 2015 at 4:58 PM, Jonathan Roelofs <jonathan at codesourcery.com> wrote:> > > On 3/17/15 5:35 PM, Steve King wrote: >> >> Clang correctly assembled a .s file when using the -integrated-as >> option. Thanks, that is news to me! However, without -integrated-as, >> clang invoked 'as', which won't work for a GNU-less target. Accepting >> assembler invocation as a good case study for target specific clang >> defaults, what is the proper solution? > > > Again, what is the target architecture? (I understand if it's an out-of-tree > backend that you can't talk about. If so, I'll stop bugging you about this > point.) > > For some targets, -integrated-as the default is on, for others it defaults > to off. It generally depends on how good the integrated assembler is for > that target. For example, the default on ARM used to be -no-integrated-as > because IAS just wasn't mature enough at the time. > > The "proper solution" here w.r.t. assemblers is to implement full support > for the integrated assembler for the target arch in llvm, and then flip the > default for that target. > > > -- > Jon Roelofs > jonathan at codesourcery.com > CodeSourcery / Mentor Embedded >
On Tue, Mar 17, 2015 at 4:58 PM, Jonathan Roelofs <jonathan at codesourcery.com> wrote:> > The "proper solution" here w.r.t. assemblers is to implement full support > for the integrated assembler for the target arch in llvm, and then flip the > default for that target. >But that is the same as saying LLVM offers no compiler driver until integrated assembly is robust for your target, no? Given that ARM took a long time to get there, why not grant other targets that grace period too?
On 3/18/15 11:13 AM, Steve King wrote:> On Tue, Mar 17, 2015 at 4:58 PM, Jonathan Roelofs > <jonathan at codesourcery.com> wrote: >> >> The "proper solution" here w.r.t. assemblers is to implement full support >> for the integrated assembler for the target arch in llvm, and then flip the >> default for that target. >> > > But that is the same as saying LLVM offers no compiler driver until > integrated assembly is robust for your target, no? Given that ARMIndeed. If there is no assembler for your target, integrated or otherwise, then either way you can't really build objects for it. I don't see what the issue is here.> took a long time to get there, why not grant other targets that grace > period too?They do, and they are offered that "grace period". The difference is that those other targets have other external assemblers (usually GNU binutils). This default isn't forced on you; you're welcome to (but encouraged not to) write a separate assembler. The MC layer has changed a lot since before the ARM backend was able to switch over, and it should be easier to get IAS going on new targets. -- Jon Roelofs jonathan at codesourcery.com CodeSourcery / Mentor Embedded