A skeleton of AIX toolchain and system linker support has been introduced in D68340, and this is a follow on patch to it.
This patch adds support to system assembler invocation to the AIX toolchain.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
- Build Status
Buildable 41718 Build 42003: arc lint + arc unit
Event Timeline
clang/lib/Driver/ToolChains/AIX.cpp | ||
---|---|---|
28 | The definition of claimNoWarnArgs is to suppress warnings for some options if they are unused, can you explain a little bit about how did you figure out that we don't want warnings for those? Some context of claimNoWarnArgs: // Claim options we don't want to warn if they are unused. We do this for // options that build systems might add but are unused when assembling or only // running the preprocessor for example. void tools::claimNoWarnArgs(const ArgList &Args) { // Don't warn about unused -f(no-)?lto. This can happen when we're // preprocessing, precompiling or assembling. Args.ClaimAllArgs(options::OPT_flto_EQ); Args.ClaimAllArgs(options::OPT_flto); Args.ClaimAllArgs(options::OPT_fno_lto); } | |
45 | GCC invokes system assembler also with options -mpwr4 and -u, I think you need to verify that do we need those? And as far as I can recall, -mpwr4 is to pick up new version AIX instruction set, and -u is to suppress warning for undefined symbols. 90% sure that we need -mpwr4(I could be wrong), but not sure about -u. | |
clang/lib/Driver/ToolChains/AIX.h | ||
26 | I saw a lot of other target also set hasIntegratedCPP() as false, but I didn't find any explanation in documentation, so I am curious that what this is about? |
clang/lib/Driver/ToolChains/AIX.h | ||
---|---|---|
26 | I also failed to find useful resources that explains the purpose of this function. The main rationales of adding it were essentially that,
I'll leave this comment open, and see if someone could enlighten us. |
clang/lib/Driver/ToolChains/AIX.h | ||
---|---|---|
26 | Only "Compiler" tools set hasIntegratedCPP() to true. Looking into it, it seems combineWithPreprocessor() uses this to decide whether the tool supports preprocessor actions so it may fold them in to one step. I think we are safe leaving this as is. |
clang/lib/Driver/ToolChains/AIX.cpp | ||
---|---|---|
45 | For the -u option, I'll be adding it to this patch with a FIXME that we'd like to remove it in the future. The rationale is that, since currently we do not have the assembly writing ready that writes the extern(s), we'll pass in this -u to suppress any related warnings. Once the assembly writing is ready, we should remove this flag as it potentially covers up for undefined symbols that are actually problematic. For the -m option, adding -many seemed to be more suitable at the moment. During code generation, the compiler should've already guaranteed that it used a correct and appropriate instruction set (i.e., conforms to the user specified driver option -mcpu=). The -m assembler option here double checks the same thing that's already been checked at codegen. That said, we can just pass in -many to accept all and rely on codegen to do the checking. On the other hand, potential problems might get away with it in one of the two scenarios I can think of right now,
With regard to GCC's behaviour, GCC would append first -mpwr4 then -many to the system assembler, which effectively means adding -many solely because the last -m flag would overwrite all its preceding one(s). |
clang/lib/Driver/ToolChains/AIX.cpp | ||
---|---|---|
28 | The original reason was that, since we are doing assembling here, and as stated in claimNoWarnArgs, there might be an unused -f(no-)?lto when we're assembling, and we'd like to suppress the warning(s) for that. Looking into it, the three options [[ https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-flto | flto, fno_lto ]] , and [[ https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang1-flto | flto_EQ ]] are used to enable/disable link time optimization, but LTO is not supported by the AIX system linker. Driver would just throw error if the user passes it -flto or -flto=<arg> on AIX, so claiming them or not currently makes no actual difference as far as I'm concerned. That being said, I don't have a strong opinion either way. Let's see how other people think. | |
clang/lib/Driver/ToolChains/AIX.h | ||
26 | I checked this function on other targets. As David pointed out, only the compiler tools would set hasIntegratedCPP() to true, the assembler and linker tools set it to false because they do not support combining with preprocessor action. |
clang/lib/Driver/ToolChains/AIX.cpp | ||
---|---|---|
28 | It's probably also worth mentioning that, adding claimNoWarnArgs does not affect those LTO options being parsed and consumed by the driver in Driver::setLTOMode. |
clang/lib/Driver/ToolChains/AIX.cpp | ||
---|---|---|
37 | Refer to the other comment regarding confusion of "as" with the English word. | |
47 | There is no FIXME here indicating the plan to remove this in the future when the assembly generation from the compiler no longer needs this. | |
49 | Minor nit: Typo: s/Acccept/Accept/; | |
50 | A comment should indicate that this behaviour matches that of GCC on Power for AIX and Linux for both the user-provided assembler source case and the compiler-produced assembler source case. The behaviour for XL with user-provided assemble source is different. | |
61 | The AIX assembler does not accept more than one input file. If the intent is to let the assembler produce the error message, then I think we should at least have a comment to acknowledge the situation. | |
clang/test/Driver/aix-as.c | ||
2 | Minor nit: To avoid confusion with the English word, use `as` or as(1) | |
32 | I am not getting how this block is related to "pthread". | |
41 | s/powerpc/powerpc64/; | |
45 | Same comment re: "pthread". |
clang/lib/Driver/ToolChains/AIX.cpp | ||
---|---|---|
28 | Turned out Driver::BuildCompilation would always call Driver::setLTOMode, which inherently sets the three LTO options to "claimed". This happens before the driver gets to assembler invocation, hence no need to call claimNoWarnArgs here. For future reference, I'm also documenting here that claimNoWarnArgs was added in rL225100, which was originally posted to fix build bots that failed due to warnings from unused LTO options. setLTOMode was introduced months later in rL250455, which claims the three LTO options during BuildCompilation. | |
61 | Good point. I didn't intend to leave this to assembler. Looking into it, when presented multiple assembly sources, the driver would invoke as to assemble each of the input files individually. This behaviour also matches that of GCC and XL. In case something goes wrong and the driver attempts to pass multiple input files to as, adding a check to guard the number of inputs probably makes sense? | |
clang/test/Driver/aix-as.c | ||
32 | Looks like I copy-pasted the wrong thing while rebasing. Good catch, thanks! |
clang/lib/Driver/ToolChains/AIX.cpp | ||
---|---|---|
68 | llvm_unreachable is not the right solution if this can be reached by "user error". We should produce a proper error message. |
clang/lib/Driver/ToolChains/AIX.cpp | ||
---|---|---|
70 | Should is also be checked as being either a filename or "nothing"? |
Add more input file handling
- Check if the input file is of type Filename or Nothing, throw assertion otherwise.
- Add a test case to verify the correct behaviour of assembler invocation when multiple input files are specified by the user.
clang/lib/Driver/ToolChains/AIX.cpp | ||
---|---|---|
68 | One risky condition I can think of is the user passes in multiple assembly sources to the driver, which may lead to multiple assembler inputs. To verify how the driver handles such a case, I added a new test into aix-as.c below, whose results suggested that this is okay because the driver would invoke as for each and every input files respectively. Looking into the code, the driver would construct an action list for each input files individually, which again matches the behaviour we observed in the testing results. That said, I believe the llvm_unreachable here is indeed not reachable by "user errors" like this, and if it triggers, it's likly an internal error. |
LGTM with minor change request to a comment. Thanks.
clang/lib/Driver/ToolChains/AIX.cpp | ||
---|---|---|
68 | Thanks. Can we indicate that we are expecting the driver to invoke as separately for each assembler source file in the comment? |
State in the comment the expectation to driver in handling assembler source input when invoking as(1).
I saw a lot of other target also set hasIntegratedCPP() as false, but I didn't find any explanation in documentation, so I am curious that what this is about?