We've been building with LLVM_ENABLE_THREADS=0 to avoid dependencies on the TLS support in the build environment. We may require assistance to restore our builds if these patches introduce a TLS dependency. @daltenty, fyi.

There's frontend changes anyway, so there should be changes for the predefined macros?

LGTM with suggestion.

In D88659#2323631, @jyknight wrote:

ISTM that comment may be incorrect. At least, the precedent set by GCC appears to be that BIGGEST_ALIGNMENT and alloca _both_ should follow vector alignment requirements of the selected ISA even when that is greater than any fundamental alignment requirement, and greater than malloc's alignment.

Thanks. This matches what I tested with a big endian host system. I'm not sure if @dweber agrees that their comments have been addressed though.

In D89064#2322717, @Xiangling_L wrote:

In D89064#2320133, @hubert.reinterpretcast wrote:

Can we use a regex to make this also work in AIX?

Sure we can also do that. May I ask is that because we prefer letting AIX support as many LIT testcases as possible?

Can we use a regex to make this also work in AIX?

In D88659#2318203, @jyknight wrote:

It seems like on AIX, __BIGGEST_ALIGNMENT__ should just be set to 16, then. I'm not sure why you want it to be 8?

LGTM; thanks.

LGTM; thanks.

In D88773#2312611, @tlively wrote:

I think the description still applies. Were you thinking of mentioning the specific error message? "C2100: illegal indirection" doesn't seem to give any more information than is already in the description.

In D88773#2309949, @tlively wrote:

• Make initializations even more MSVC-friendly

I can confirm that at least llvm/test/CodeGen/WebAssembly/simd-build-vector.ll is good on AIX (big-endian Power) with this patch (at least with the maskTrailingOnes<uint64_t>(LaneBits)) change.

@uweigand, fyi re: clang-s390x-linux bot: https://reviews.llvm.org/D88591#2308590.

This patch appears to be the likely cause of big endian hosts failing with a timeout: http://lab.llvm.org:8011/builders/clang-s390x-linux/builds/35450

This sounds right. @daltenty, can you confirm that this works on the AIX builds?

LGTM; thanks!

LGTM.

@jasonliu: There's a lot of test adjustments to explicitly use the non-default, but I am not sure there is testing here to validate that the llc default when producing XCOFF assembly/object output is with unique data sections.

@vsk, there are bot failures with backtraces that mention dropLocation, e.g., http://lab.llvm.org:8011/builders/llvm-avr-linux/builds/6257/steps/ninja%20check%201/logs/stdio:

Stack dump:
0.	Program arguments: /home/buildbot-worker/llvm-avr-linux/llvm-avr-linux/stage1/./bin/clang -Wno-suggest-override -DGTEST_NO_LLVM_SUPPORT=1 -DGTEST_HAS_RTTI=0 -I/home/buildbot-worker/llvm-avr-linux/llvm-avr-linux/llvm/llvm/utils/unittest/googletest/include -I/home/buildbot-worker/llvm-avr-linux/llvm-avr-linux/llvm/llvm/utils/unittest/googletest -I/home/buildbot-worker/llvm-avr-linux/llvm-avr-linux/llvm/compiler-rt/include -I/home/buildbot-worker/llvm-avr-linux/llvm-avr-linux/llvm/compiler-rt/lib -I/home/buildbot-worker/llvm-avr-linux/llvm-avr-linux/llvm/compiler-rt/lib/sanitizer_common -fno-rtti -O2 -Werror=sign-compare -Wno-non-virtual-dtor -Wno-gnu-zero-variadic-macro-arguments -gline-tables-only -m64 -c -o SANITIZER_TEST_OBJECTS.sanitizer_allocator_test.cpp.x86_64.o /home/buildbot-worker/llvm-avr-linux/llvm-avr-linux/llvm/compiler-rt/lib/sanitizer_common/tests/sanitizer_allocator_test.cpp 
1.	<eof> parser at end of file
2.	Per-module optimization passes
3.	Running pass 'Function Pass Manager' on module '/home/buildbot-worker/llvm-avr-linux/llvm-avr-linux/llvm/compiler-rt/lib/sanitizer_common/tests/sanitizer_allocator_test.cpp'.
4.	Running pass 'Simplify the CFG' on function '@_ZN11__sanitizer12SizeClassMapILm3ELm4ELm8ELm17ELm128ELm16EE5PrintEv'
 #0 0x00007f68219df64c llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/home/buildbot-worker/llvm-avr-linux/llvm-avr-linux/stage1/bin/../lib/libLLVMSupport.so.12git+0x1a764c)
 #1 0x00007f68219dd324 llvm::sys::RunSignalHandlers() (/home/buildbot-worker/llvm-avr-linux/llvm-avr-linux/stage1/bin/../lib/libLLVMSupport.so.12git+0x1a5324)
 #2 0x00007f68219dd5b5 llvm::sys::CleanupOnSignal(unsigned long) (/home/buildbot-worker/llvm-avr-linux/llvm-avr-linux/stage1/bin/../lib/libLLVMSupport.so.12git+0x1a55b5)
 #3 0x00007f68218ed228 CrashRecoverySignalHandler(int) (/home/buildbot-worker/llvm-avr-linux/llvm-avr-linux/stage1/bin/../lib/libLLVMSupport.so.12git+0xb5228)
 #4 0x00007f68210fcf20 (/lib/x86_64-linux-gnu/libc.so.6+0x3ef20)
 #5 0x00007f682214aa74 llvm::Instruction::getFunction() const (/home/buildbot-worker/llvm-avr-linux/llvm-avr-linux/stage1/bin/../lib/libLLVMCore.so.12git+0x1b8a74)
 #6 0x00007f68220d8a8a llvm::Instruction::dropLocation() (/home/buildbot-worker/llvm-avr-linux/llvm-avr-linux/stage1/bin/../lib/libLLVMCore.so.12git+0x146a8a)
 #7 0x00007f6823b16c81 llvm::FoldBranchToCommonDest(llvm::BranchInst*, llvm::MemorySSAUpdater*, llvm::TargetTransformInfo const*, unsigned int) (/home/buildbot-worker/llvm-avr-linux/llvm-avr-linux/stage1/bin/../lib/libLLVMTransformUtils.so.12git+0x1d8c81)
 #8 0x00007f6823b205fc llvm::simplifyCFG(llvm::BasicBlock*, llvm::TargetTransformInfo const&, llvm::SimplifyCFGOptions const&, llvm::SmallPtrSetImpl<llvm::BasicBlock*>*) (/home/buildbot-worker/llvm-avr-linux/llvm-avr-linux/stage1/bin/../lib/libLLVMTransformUtils.so.12git+0x1e25fc)

LGTM with minor comments.

• Update to avoid stored format string by using switch on a enum value

@ldionne, does this patch look okay to you? In terms of changes being made for z/OS, it's mainly going to be:

LGTM; thanks.

In D88301#2295423, @ldionne wrote:

I think it does. The issue is that we're not detecting _LIBCPP_HAS_NO_ALIGNED_ALLOCATION properly.

I don't think this patch makes sense given D87611. @Kai, @fanbo-meng, @abhina.sreeskantharajan, @zibi, fya.

In D88309#2295312, @steven_wu wrote:

I am fine with adding such a C API but I want to make sure you think through all the options, not just adding a new stable C API that is going to be thrown away.

In D88309#2295142, @steven_wu wrote:

• If this is just a temporary workaround, I would resist make this change to bake in this API that will not be used in the future.

Off-list discussion seems to indicate that only the NFC portion of the patch was intended to be approved.
That is, the scope of this patch is supposed to be https://reviews.llvm.org/D88105?id=293625 plus formatting changes.

LGTM; thanks.

Looks to me that this (since it is approved) completely replaces D88130. The patch description needs to be changed of course.
Not sure if the committer wants to try splitting out the non-AIX test as an NFC patch.

LGTM; thanks.

LGTM; thanks.

In D87877#2288974, @efriedma wrote:

I haven't been following this closely, but is there some reason we can't transform powf(x, 0.5) to sqrt(x == -infinity ? qnan : x)?

• Rebase on top of D88066; add isKnownNeverInfinity condition
• Adjust comment for afn case

In D87113#2279690, @daltenty wrote:

Compiler-rt supports generating multiple targets from a single configuration. By default the compiler-rt build process will figure out the supported arches and generate different targets for the powerpc and powerpc64 objects, so there is only one real run.

General comment: CMake is not the only mechanism for making the conditions common; a header file is capable of the same.

LGTM; thanks.