Generating object files more efficiently


XYZ is your actual architecture? Are you trolling?


There’s a function in lib/Driver/ToolChains/CommonArgs.cpp called tools::getCPUName that needs to be implemented for each target to determine how to process -mcpu/-march

You might be able to bypass that for testing purposes by adding “-Xclang -target-cpu -Xclang mycpu” to your driver command line.


You said "XYZ" was your "actual architecture." That doesn't sound like an example to me.


It's both a) not me, and b) irrelevant to the discussion. Please try
to keep emails to the list on topic and not inflammatory.



How do I tell clang to use my target CPU’s assembler instead of my host’s assembler? I found the -fuse-ld option to tell it to use my linker but didn’t find an option for the assembler.

There isn’t an option to specify a particular assembler. You can use -fno-integrated-as to tell Clang to run the as tool instead of trying to generate the object file itself. If you can’t arrange for your target’s assembler to be in the right place and named as then you have two choices: (1) have Clang emit assembler source with the -S option and run the correct assembler directly; (2) support your target more thoroughly in Clang’s ‘Driver’ component, so that Clang knows what to do when you specify -fno-integrated-as.


Thanks, Paul.
How do I generate the ‘as’? When I look at the bin directory , there is an llvm-as that takes llvm assembly as input but no ‘as’.

Perhaps I misunderstood your description. When you said you wanted Clang to “use my target CPU’s assembler instead of my host’s assembler” it sounded to me like you already had some other (non-LLVM) assembler for your target CPU, and you wanted Clang to run that (non-LLVM) assembler. What I said previously was guided by that interpretation.

But, perhaps you meant that you are seeing Clang taking the code you generate for your target, and then trying to assemble it as if it were code generated for your host. That sounds like you have not implemented all the necessary pieces of Target and MC to turn the generated code into an object file for your target.

Let’s try this: If you run clang –S –target your_triple test.c (where your_triple is the triple for your target) does it produce an assembler file (test.s) that has the proper instructions for your target? If not, then you have some work to do to make that happen.

Once your assembler file looks good, if you run clang –c –target your_triple test.s what happens?


I see that in your first command, you don’t supply the triple:

  1. First clang -emit-llvm test.c -o test.bc

but you do supply it in the second command:

2)Then llc -my_triple test.bc -filetype=obj

Is this an oversight, or have you been omitting the triple when you run Clang?

Do I understand correctly that when you do “clang –target my_triple –c test.c” then the wrong things happen?

If the wrong things happen when you give Clang your triple, that suggests that you have the LLVM part hooked up correctly for your target but not the Clang part. Clang, separately from LLVM, needs to know some things about your triple and pass information down to LLVM. This is partly in the Basic and partly in the Driver libraries within Clang. I’ve never personally added a new target so I am fuzzy on the details, but if you start looking around in those areas you will probably get a better idea of what is needed.