Our compiler team is working on productizing an LLVM compiler to replace a (mostly) proprietary toolchain. As part of this work, we have a need to support input that utilizes a non-standard assembly syntax which can be processed via a separate, external assembler to generate an object file.
After some level of investigation, I chose to add a new driver type to Types.def with the same attributes as “assembler” besides the name. This allows users to use a single driver executable (clang) for all inputs and avoid having to explicitly know about the external tool due to the availability of the ‘-x ’ option.
I then overrode SelectTool for our ToolChain object so that assemble actions with this new type go through the external assembler. This unexpectedly didn’t work due to Driver::ConstructPhaseAction’s special case which states that “some types skip the assembler phase” and hard-codes a special case which specifies that only Assemble actions with inputs of type types::TY_PP_Asm actually construct Assemble actions.
The result of this is that my new type does not construct an Assemble action, and the assembly file gets passed directly to the linker to fail.
I could certainly add my new type to this special case (and all other similar special cases, should they exist), but this difficulty hints at fitting a square peg into a round hole. One option might be types::onlyAssembleType, which doesn’t seem to be called anywhere in my current copy of the source. This function returns true for: assembler, assembler-with-cpp, and my new type. I don’t think having it return true for assembler-with-cpp is an issue because that type will never attempt to construct an Assemble action with an Input of types::TY_Asm type. Instead, it will first create a Preprocess action to take Input types::TY_Asm to output type types::TY_PP_Asm, and then construct a separate Assemble action with Input types::TY_PP_Asm, as desired.
Does types::onlyAssembleType (phases contain Assemble, but not Compile or Backend) have promise as the decider for the special case in Driver::ConstructPhaseAction? Does my original implementation concepts regarding a new driver type seem solid?