This patch enables support that the XL compiler had for AIX under -qdatalocal/-qdataimported.
Details
Diff Detail
Event Timeline
clang/include/clang/Basic/DiagnosticFrontendKinds.td | ||
---|---|---|
93 ↗ | (On Diff #535088) | More conventionally, we use a driver warning in DiagnosticDriverKinds.td. Please read https://llvm.org/docs/CodingStandards.html#error-and-warning-messages In Clang, the conventional message reads: ignoring ... because ... |
clang/include/clang/Driver/Options.td | ||
2921 | Make sure AIX-specific options have TargetSpecific flag. |
clang/include/clang/Basic/DiagnosticFrontendKinds.td | ||
---|---|---|
93 ↗ | (On Diff #535088) | The problem with the driver warning approach is that the code that performs the filtering will be in CodeGen/TargetInfo.cpp, AIXTargetCodeGenInfo::setTargetAttributes and it seems to me we won't have access to Driver. In TargetInfo.cpp all of the diagnostics I see are of the FrontendKind, and I am following the same approach. |
clang/include/clang/Driver/Options.td | ||
2921 | These are not meant to be target-specific to AIX. It's just that this patch only implements setTargetAttributes on AIX; on other platforms we would like these options to simply be ignored. |
clang/include/clang/Driver/Options.td | ||
---|---|---|
2921 | TOC is PowerPC specific so TargetSpecific is still applicable. CoreOption is only needed if you want to support Windows clang-cl |
test/CodeGen/PowerPC/toc-data-structs-arrays.cpp | ||
---|---|---|
2 ↗ | (On Diff #539608) | -target has been deprecated since Clang 3.4. Use --target= for new tests. %clang and %clang++ are normally only for test/Driver. Use %clang_cc1 for codegen tests. |
%clang and %clang++ are normally only for test/Driver. Use %clang_cc1 for codegen tests.
But %clang_cc1 doesn't compile c++ and one of the codegen tests involves vectors. What do you suggest for that?
On most targets (I am not familiar with AIX), clang -c a.cc is identical to clang++ -c a.cc. clang++ just additionally links libstdc++/libc++ for the link action.
You can use -### to dump cc1 options and find the useful one for your %clang_cc1 command.
You can use -### to dump cc1 options and find the useful one for your %clang_cc1 command.
I've done this and determined which options need to be added but I don't see any precedent for this in CodeGen tests. For example no CodeGen test has -I /usr/include. It seems either way, using clang++ or adding these extra options, I will break a precedent
For non-Driver tests, use %clang %s -###
No CodeGen test has -I /usr/include, as we try to avoid inclusion which may be different from one machine to another.
Your test doesn't need any #include. Even if it does, try faking them, e.g. many C++ tests use namespace std { ... class initializer_list to declare std declarations they need.
lib/Driver/ToolChains/Clang.cpp | ||
---|---|---|
7043 ↗ | (On Diff #539608) | hasArg performs claim internally. |
7046 ↗ | (On Diff #539608) | Args.claimAllArgs(options::OPT_mtocdata_EQ, options::OPT_mno_tocdata_EQ, ...) |
7051 ↗ | (On Diff #539608) | This is not needed. Making the options TargetSpecific gets the err_drv_unsupported_opt_for_target checking: D151590 |
test/Driver/toc-conf.c | ||
1 ↗ | (On Diff #539608) | For %clang, avoid Clang 3.4 deprecated -target . Use --target= for new tests. |
The tests appear to have gone missing on the revision of this patch I reviewed.
lib/CodeGen/Targets/PPC.cpp | ||
---|---|---|
277 ↗ | (On Diff #540140) | There are some code paths where you don't need to evaluate the explicit tocdata/no-tocdata if it would have been redundant to the default already specified so you could be more efficient. |
283 ↗ | (On Diff #540140) | Is this to say that the driver sets the cc1 call to ensure no variable shows up in both lists? |
lib/Driver/ToolChains/Clang.cpp | ||
---|---|---|
7136 ↗ | (On Diff #541525) | unless there's a performance reason for keeping the if out of the loop, the code reads a little tighter if you push the if inside a single for loop. I don't feel strongly but thought I'd point it out. Use your discretion. |
test/CodeGen/PowerPC/toc-data-attribute.c | ||
12 ↗ | (On Diff #541525) | j is overaligned to be toc data. Are you expecting a diagnostic or for it to be quietly handled notoc-data? I suggest splitting out the symbols that can't be toc data to another test and check for a diagnostic. If they're warnings then I suggest also checking that the IR did not apply the toc-data attribute. |
lib/CodeGen/Targets/PPC.cpp | ||
---|---|---|
277 ↗ | (On Diff #540140) | This is true about UserSpecifiedNotTOC but we need to determine UserSpecifiedTOC even if we compile with -mtocdata because we only emit diagnostics for variables which are explicitly specified as toc-data. |
283 ↗ | (On Diff #540140) | Yes, that's right. |
lib/Driver/ToolChains/Clang.cpp | ||
7136 ↗ | (On Diff #541525) | Good point! I'll change it |
test/CodeGen/PowerPC/toc-data-attribute.c | ||
12 ↗ | (On Diff #541525) | I am expecting a diagnostic. I initially added another test verifying the diagnostics for symbols that can't be toc-data; I will add it back. |
include/clang/Basic/DiagnosticFrontendKinds.td | ||
---|---|---|
96 ↗ | (On Diff #541525) | It seems the current state of the implementation may warrant a warning when using toc-data with the large code model. The feature is only effective if TOC-based relocations are used to refer to the toc-data symbol. Has that been implemented? |
clang/test/Driver/tocdata-mcmodel-large-warning.c | ||
---|---|---|
1–8 ↗ | (On Diff #541647) | Use -### for driver test to:
Aside from this driver test for the warning, this patch does not seem to have driver tests for validating that the option is passed to -cc1 if and only if it should be. The missing tests should be added. |
include/clang/Basic/DiagnosticDriverKinds.td | ||
555 ↗ | (On Diff #541647) | Typo fix. |
lib/Driver/ToolChains/Clang.cpp | ||
7122–7124 ↗ | (On Diff #541647) | When emitting this message, the option should truly be ignored (e.g., driver should not pass the option to -cc1). Also, -mcmodel=medium is mapped by the driver to -mcmodel=large for AIX targets. The warning (and corresponding tests) should be extended to cover that. |
clang/test/Driver/tocdata-mcmodel-large-warning.c | ||
---|---|---|
1–8 ↗ | (On Diff #541647) |
Okay, I see test/Driver/toc-conf.c now. It looks like the patch was not generated with a consistent root directory? |
clang/test/CodeGen/PowerPC/toc-data-attribute.c | ||
---|---|---|
2 | Clang IR codegen tests do not require the LLVM target to be enabled. | |
clang/test/CodeGen/PowerPC/toc-data-diagnostics.c | ||
2 | Same comment. | |
clang/test/CodeGen/PowerPC/toc-data-structs-arrays.cpp | ||
2 | Same comment. | |
clang/test/Driver/toc-conf.c | ||
2–6 | No need for -S with test based on -###. |
clang/docs/UsersManual.rst | ||
---|---|---|
3159 | What do you mean by "global variable"? Do internal linkage variables at global scope count? Do variables in named C++ namespaces (or static data members of classes) count? How are they to be named by the options? I guess block-scope variables with static storage duration don't count. Whether they count or not, the effect of applying "blanket" -mtocdata upon such variables should be tested. |
clang/test/CodeGen/PowerPC/toc-data-attribute.c | ||
---|---|---|
45 | You expect to see j in the IR, just that it shouldn't have the toc-data attribute. Perhaps it's better to check the positive (with the #0 omitted) because the check-not may be satisfied if there is a subtle change in how j is emitted. This comment applies to multiple instances. | |
clang/test/Driver/toc-conf.c | ||
15 | nit: these read easier if the checks appear in the same order as the RUN steps above. | |
16 | I assume you're checking that the -mno-tocdata property is passed on the cc1 invocation. This would read better if the cc1 were part of the match. |
clang/docs/UsersManual.rst | ||
---|---|---|
3159 |
For the IBM XL compiler, block-scope variables with static storage duration do become toc-data when they are not part of the static pool (e.g., block-scope static in a C++ inline function). |
clang/lib/CodeGen/Targets/PPC.cpp | ||
---|---|---|
275 | This use of getGlobalIdentifier (having a user-interface that relies on its format) seems novel. It warrants updating the Doxygen description of the function. I believe some discussion should be had on LLVM Discourse about this. |
lib/CodeGen/Targets/PPC.cpp | ||
---|---|---|
274 ↗ | (On Diff #541525) | @hubert.reinterpretcast and I were discussing whether or not this query is the right query to use because you're string comparing the value against a string provided by the user on the command line. I think it's probably safer to use a well-defined linkage name for the comparison and set it up such that we don't unnecessarily compute it unless the toc-data feature is opted into. We should discuss offline and update this thread with our conclusion. |
clang/test/CodeGen/PowerPC/toc-data-structs-arrays.cpp | ||
---|---|---|
21 | Back-end currently does not like this. Need a change to https://github.com/llvm/llvm-project/blob/7dfe62327db81cc5ee3e29a994818370d95dc9e3/llvm/lib/Target/PowerPC/PPCISelDAGToDAG.cpp#L545. |
clang/lib/CodeGen/Targets/PPC.cpp | ||
---|---|---|
275 | I think clang::DeclarationName::getAsIdentifierInfo would be reasonable way to do it. This is a facility for printing user readable names and it makes sense to me that it would be the string a user would expect to use when specifying the command line option. If the variable isn't a simple name then it isn't eligible for toc-data. The more desirable way to to this would be a source-level attribute, which is something that ought to be considered in conjunction with this work, though I understand this is primarily to have an equivalent of the XL -qdatalocal= option for AIX. |
clang/lib/CodeGen/Targets/PPC.cpp | ||
---|---|---|
275 | clang::DeclarationName::getAsIdentifierInfo sounds like it would not take scopes and linkage into account. It also sounds like it has additional complications around macros. Limiting the ability to specify specific symbols to cases of external linkage using the mangled symbol names is perhaps the least controversial in terms of having something that is solid (albeit restrictive). |
clang/lib/Driver/ToolChains/AIX.cpp | ||
---|---|---|
531 | nit: indent |
Here are some group review comments from today's session.
Also, can we summarize the user manual in the patch description?
clang/docs/UsersManual.rst | ||
---|---|---|
3156 | ||
3159 | Add a description to what is done with the toc-data attribute. | |
3159 | We should describe here:
| |
3167 | Add double quotes for options. | |
clang/include/clang/Basic/DiagnosticDriverKinds.td | ||
558 | Just say that it's only supported for small code model. | |
clang/include/clang/Driver/Options.td | ||
3409 | ||
3416 | Can we move this under the option on 2957 (put positive and negative options together) and ensure the HelpTexts are updated accordingly? | |
clang/lib/Driver/ToolChains/AIX.cpp | ||
504 | I think this is only used once. We can probably move this down to near the place we need it, right? | |
508 | End with period. | |
509 |
| |
514 | Add a comment that this checks how the global TOC attribute is set. | |
518 | Add a null check for LastArg. | |
525 |
| |
527 | Add a comment on when and how we get into the else block. | |
533 | I think this can go away and explicitly check if the option type matches the TocDataInEffect. | |
536 | Add a comment to specify that we're going through the list of exceptions to the globals. | |
539 |
| |
543 |
|
One last comment from the group code review.
clang/lib/Driver/ToolChains/AIX.cpp | ||
---|---|---|
566 | What is inside the if/else are similar. If they're the same, maybe we can set a variable inside the if/else and then move the other lines out of the if/else. |
clang/docs/UsersManual.rst | ||
---|---|---|
3156 | @syzaara, I see the comment has been addressed but it is not marked as "done". The author is responsible for marking comments as "done" in Phabricator. Please mark all comments that you believe have been addressed as "done" so that other parties know if the comment is still pending action. | |
3161 | The "toc-data attribute" is an implementation detail. The user-facing documentation should not talk about it. | |
3173 | Please document the conditions for a variable to be "suitable". | |
3178 | The use of "all" is incorrect. Please qualify with "suitable" (and address this issue elsewhere in the text where applicable). |
clang/include/clang/Driver/Options.td | ||
---|---|---|
3411 | Our situation with these options is a bit more complicated because -mno-tocdata= is not just removing the entries that were specified by -mtocdata= -mtocdata=X -mno-tocdata=X -mtocdata=Y,Z,S Then we could potentially just forward to CC1: -mtocdata=Y,Z,S Rather than what we currently forward: -mno-tocdata -mtocdata=Y,Z,S However, if we have -mtocdata -mno-tocdata=Y,Z,S This means all suitable variables by default will become toc-data aside from the exceptions in -mno-tocdata=Y,Z,S So the way we handle it is by passing to CC1 either -mtocdata -mno-tocdata= or -mno-tocdata -mtocdata= which is the current default setting along with the exceptions that need to be applied to that default setting. |
clang/include/clang/Driver/Options.td | ||
---|---|---|
3405 | do we need CLOption, DXCOption here ? these two option is for Window OS. ? |