I was wondering where are the test cases in this patch. Did they get missed when updating the revision?

• Add a P6+VSX run line and remove extra P7/P8 lines for backend test

Ping.

Address review comments:

• Remove -no-opaque-pointers and updates CHECKs
• Simplify runs and checks of C and IR test files

Address review comments of adding documentation to clang/docs/ClangCommandLineReference.rst and adding AIX checks to clang/test/Driver/ppc-crbits.cpp.

LGTM.

In D119136#3459738, @alanphipps wrote:

We've also been seeing failures in our downstream Arm compiler when running the Perennial C++14 compliance tests related to this change. Specifically, the tests expect a diagnostic to be issued when the lambda capture variable is outside of the lambda's {} scope. Another tests uses the lambda capture variable in a decltype-style return type which is also outside of the scope.

Do these failures sound like what others have run into?

Also, a minor nit I found, but please do update the title and description of the revision to say register rather than regsiter.

I think this LGTM.

Thanks Quinn. I think this overall LGTM.

Overall this change looks good to me, although I do have one question.

I think this also LGTM.

Thanks for adding this David, I think this makes sense and LGTM, too.

Ping.

@tstellar I was wondering if it's possible to cherry-pick this patch to the LLVM 14 release branch/how can we go about backporting this patch? Any assistance is greatly appreciated!

In D118357#3294942, @tstellar wrote:

This seems fine.

@tstellar Just wanted to double check with you in case you had any objections to this patch. I'd like to commit it and would also like it added to the release branch (after it's committed).

In D112748#3273779, @ldionne wrote:

Rebase onto main. Gentle ping!

Also LGTM.

Overall LGTM.

LGTM, too.

In D116743#3250956, @stefanp wrote:

In D116743#3227465, @amyk wrote:

nit: The description has regsiter a number of times, please update it to register

This a ver useful patch. Thanks Stefan! I have a question (might be silly but...), if verbose asm is enabled by default, does it require an update to more than the two test cases that you've updated in this patch?
(I guess what I am getting at here is if verbose asm is enabled by default, I would have expected a whole bunch of other tests to also require updating, but I may be misunderstanding here.)

For some reason I always seem to typo the word register. Not sure why... Anyway, thank you for finding them.

Not a silly question at all!
Initially I thought that I didn't need to update the tests because I wan't changing code and the CHECK/CHECK-NEXT lines don't really care that there are comments that come after the instructions. This is true in most cases but there are tests that already have a comment after the instruction line (for example # 8-byte Folded Spill) and in those cases by adding a second comment I'm adding a new line and the CHECK-NEXT lines don't work anymore. Anyway, I'm going to update those tests now.

Address Nemanja's comments:

• Pulling out the code and guarding it for P9 and above
• Update test cases affected by the change
• Update the handling to:
  • Bitcast the vector
  • Bitcast the scalar
  • Produce the v4i32 vector insert
  • Bitcast and return the result

Address Nemanja's review comments:

• Add a comment as to why extending loads are allowed for i8/i16 types (because they're not legal types)
• Change the cast to LoadSDNode to dyn_cast, add early exits

Ping.

Ping.

nit: The description has regsiter a number of times, please update it to register

Thanks for the insight into the problem on the macOS side, @paquette.
@Meinersbur I was also wondering if you also have any thoughts regarding this issue?

In D115042#3199081, @paquette wrote:

Hi @amyk, this seems to have broken our public CTMark builders. Can you take a look? Thanks!

https://green.lab.llvm.org/green/job/lnt-ctmark-aarch64-O0-g/11207/

LGTM, thank you Nemanja.

In D115285#3180820, @ZarkoCA wrote:

The change seems fine but would you mind adding the reason why this test is not expected to pass on AIX in the description?

In D115042#3183125, @Meinersbur wrote:

LGTM

Updated the revision to use CMAKE_C_COMPILER_ID as suggested by @Meinersbur.
This approach will set TEST_SUITE_HOST_CC as clang is the CMAKE_C_COMPILER is also clang. It also respects if I set TEST_SUITE_HOST_CC in CMake.

In D115042#3176437, @Meinersbur wrote:

CMAKE_C_COMPILER does not work here in all cases. In particular, when cross-compiling using gcc. For instance, I would like to cross-compile to an embedded ARM board on my x86_64 desktop. I'd configure CMake to aarch64-linux-gnu-gcc as CMAKE_C_COMPILER. Hence that llvm_add_host_executable would compile to aarch64, not my x86_64 host.

TEST_SUITE_HOST_CC is a cmake configuration parameter, the idea is that you change it to something else if your host compiler is not cc. You could detect whether CMAKE_C_COMPILER is clang and if so, use that compiler has default host compiler since it uses -target to cross-compile.

In D115105#3174149, @ldionne wrote:

Nitpick: In your commit message, I think you mean LLVM_ENABLE_RUNTIMES, not LLVM_ENABLE_PROJECTS.

I'm fine-ish with this change. Another approach would be D112748, where we automatically route various runtimes to LLVM_ENABLE_RUNTIMES without having to change how test-release.sh is invoked. I'm fine with either, I don't really have a preference.

Thanks for putting up this patch (and taking a look at the revision I've put up). I've left a question on this patch to keep the conversation more contained.

My initial thought with this patch was to add the ability to supply the list of projects by a semicolon delimited
list with the --runtimes option, but of course, feedback is welcome with how exactly we want to achieve this
with test-release.sh and this method may not be the best way.

Also, I noticed that I think you may have meant to put [PowerPC] Handle Vector Sum Reduction instead of [PowerPC] Handle Vector Sum Reducation for the title. :-)

I put up this patch as when trying to configure and build test-suite on an AIX system, I was not able to use the default cc on the machine to compile the test-suite tools.
I figured the proper solution would probably be to use ${CMAKE_C_COMPILER}, and perhaps this was the original intention, but are you able to confirm if this is the proper thing to do? Was there any justification for doing just cc in the first place?