Page MenuHomePhabricator

Add AIX assembler support

Authored by stevewan on Oct 30 2019, 9:07 AM.



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.

Diff Detail

Event Timeline

stevewan created this revision.Oct 30 2019, 9:07 AM
Herald added a project: Restricted Project. · View Herald TranscriptOct 30 2019, 9:07 AM
Xiangling_L added inline comments.Nov 15 2019, 10:03 AM

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.

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.


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?

stevewan marked an inline comment as done.Nov 15 2019, 10:43 AM
stevewan added inline comments.

I also failed to find useful resources that explains the purpose of this function. The main rationales of adding it were essentially that,

  1. It's a pure virtual function in the base Tool class,
  2. Most if not all of other targets had overridden this function such that it returns false.

I'll leave this comment open, and see if someone could enlighten us.

daltenty added inline comments.Nov 18 2019, 7:05 AM

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.

stevewan marked an inline comment as done.Nov 19 2019, 10:44 AM
stevewan added inline comments.

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,

  1. User passes in a .s assembly file that uses instructions from the super-set of what's specified in -mcpu=. This is mostly on the user side because essentially they pass in contradictory inputs that are not going to fly.
  2. User passes in a .c source file, but codegen hit some issue and falsely decides to use a super-set of what's specified in -mcpu=. Given that we don't have codegen ready yet, we don't know how reliable it might be. I would suggest that we keep -many as it is for now, and we may change it when needed once we are more clear on code generation.

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).

stevewan marked 4 inline comments as done.Nov 20 2019, 5:53 PM
stevewan added inline comments.

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 [[ | flto, fno_lto ]] , and [[ | 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.


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.

stevewan updated this revision to Diff 230360.Nov 20 2019, 6:20 PM
stevewan marked an inline comment as done.

Add "-u" to accept undefined symbol as extern.

stevewan marked an inline comment as done.Nov 20 2019, 6:31 PM
stevewan added inline comments.

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.


Refer to the other comment regarding confusion of "as" with the English word.


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.


Minor nit: Typo: s/Acccept/Accept/;


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.


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.


Minor nit: To avoid confusion with the English word, use




I am not getting how this block is related to "pthread".




Same comment re: "pthread".

stevewan updated this revision to Diff 231000.Nov 25 2019, 7:35 PM
stevewan marked 12 inline comments as done.

Remove claimNoWarnArgs, limit the number of input files, and add more comments.

stevewan marked an inline comment as done.Nov 25 2019, 8:08 PM
stevewan added inline comments.

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.


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?


Looks like I copy-pasted the wrong thing while rebasing. Good catch, thanks!

daltenty accepted this revision.Nov 29 2019, 6:12 AM

Other than minor nit, LGTM


nit: plural, "files"

This revision is now accepted and ready to land.Nov 29 2019, 6:12 AM
stevewan updated this revision to Diff 231557.Nov 29 2019, 9:01 AM

Correct a typo in a comment.

stevewan edited the summary of this revision. (Show Details)Nov 29 2019, 9:02 AM
stevewan marked 2 inline comments as done.

llvm_unreachable is not the right solution if this can be reached by "user error". We should produce a proper error message.


Should is also be checked as being either a filename or "nothing"?

stevewan updated this revision to Diff 231579.Nov 29 2019, 4:59 PM

Add more input file handling

  1. Check if the input file is of type Filename or Nothing, throw assertion otherwise.
  2. Add a test case to verify the correct behaviour of assembler invocation when multiple input files are specified by the user.
stevewan marked 3 inline comments as done.Nov 29 2019, 5:54 PM
stevewan added inline comments.

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.

stevewan marked an inline comment as done.Nov 29 2019, 5:55 PM

LGTM with minor change request to a comment. Thanks.


Thanks. Can we indicate that we are expecting the driver to invoke as separately for each assembler source file in the comment?

stevewan updated this revision to Diff 231712.Dec 2 2019, 7:55 AM

State in the comment the expectation to driver in handling assembler source input when invoking as(1).

stevewan marked an inline comment as done.Dec 2 2019, 7:56 AM
daltenty accepted this revision.Dec 2 2019, 8:27 AM
This revision was automatically updated to reflect the committed changes.