LGTM.

LGTM.

Also check for sys/wait.h, and rename the feature to has-unix-headers.

Looks good, I'll commit this for you.

In D122959#3475470, @ZhiyaoMa98 wrote:

I would like to add a test, but I do not know how. My understanding is that I will need to create an example that PrologueMBB has non-immediate predecessors. Is there any example I can follow? Thanks!

After doing some more experimentation I don't think it's possible to get this to work in all cases. If we make a copy of the closure then any containers in it will be copied, but copies of iterators will still point to the container outside of the closure copy, and this causes a bunch of tests to fail.

In D124255#3470538, @ldionne wrote:

This looks really interesting! However, doesn't that mean that we can't assert that the process terminates if a certain condition is met?

Also adjust aarch64-v8.2a-fp16-intrinsics-constrained.c in this patch (was previously done in
D115620) and remove the checks of the generated asm.

Removed clang test changes.

Ping.

This is interacting badly with MachineCSE, as the presence of a physical register prevents it from optimising in some cases. I think the fix is in MachineCSE, but removing this patch from review while I look at it.

I don't know much about this specific bit of code, but a comment in ReplaceUsesOfBlockWith mentions that it's expected that 'Old' is a successor of 'this' so the fix looks reasonable. However, could you also add a test for this?

Adjusted formatting slightly.

In D115352#3399965, @dmgreen wrote:

The original version of this patch was altering the non-strict codegen because the flags were lost in the machine combiner. Have you done any other testing to make sure that doesn't happen anywhere else? To make sure this doesn't pessimise the performance for the default non-strict case.

llvm/test/CodeGen/AArch64/fp-intrinsics-vector.ll is testing the asm generation, so it probably is fine to remove that here so I will. This test is specifically testing arm_neon.h intrinsics though, so wouldn't make sense unifying with other architectures.

Rebase and ping.

Rebase and ping.

Ping.

LGTM, but please adjust the comment in ARMISelLowering.cpp as suggested by the clang-format linter before committing.

LGTM as well.

Ping.

Ping.

Ping.

Rebased.

Rebased, and also adjusted formatting slightly.

In D118259#3275297, @fhahn wrote:

Does this clang test actually need to check the generated assembly? Shouldn't it be enough to check that the correct intrinsics are generated?

Use ReplaceAllUsesOfValueWith instead of MorphNode.

Added tests for fnmadd and fnmsub.

Morph the strict_fadd instead of creating a new one, so that we don't end up with two strict_fadd nodes (as both would be kept when exceptions are enabled).

Adjusted loops so that the formatting matches what clang-format prefers. It turns out that non-strict f128 fmaximum/fminimum doesn't work, so I've added a FIXME comment about that and just added tests for non-f128.

Is a f128 fminimum / fmaximum something that should be handled? I don't see any tests for fminimum in general.

Yes, it should, I'll do that and add tests.

You'll want to have the RUN lines for the thumb tests to have a --check-prefix argument to FileCheck that's unique, and use that to check for the thumb-specific codegen, e.g.

; RUN: llc < %s -mtriple=arm-linux-androideabi -mattr=+v4t -verify-machineinstrs | FileCheck %s -check-prefix=ARM-android
; RUN: llc < %s -mtriple=arm-linux-unknown-gnueabi -mattr=+v4t  -verify-machineinstrs | FileCheck %s -check-prefix=ARM-linux
; RUN: llc < %s -mtriple=thumb-linux-androideabi -mattr=+v4t -verify-machineinstrs | FileCheck %s -check-prefix=THUMB-android
; RUN: llc < %s -mtriple=thumb-linux-unknown-gnueabi -mattr=+v4t  -verify-machineinstrs | FileCheck %s -check-prefix=THUMB-linux

then later

; THUMB-android:      test_large:

Please add a test for this. llvm/test/CodeGen/ARM/segmented-stacks.ll already has some tests related to this, so it looks like you could add a couple of RUN lines for thumb and thumb2 targets, and add test_very_large that's like test_large but with an integer that's too large for ARM::MOVi.

Update based on review comments and adjust formatting.

Moved a couple of setOperationAction lines from D117795 to here.

Also preserve flags in TargetInstrInfo::reassociateOps (which is called from TargetInstrInfo::genAlternativeCodeSequence).

I've created D118621 for making the AArch64 machine combiner patterns preserve MIFlags.

The performExtractVectorEltCombine transformation doesn't work correctly when D115352 is applied (it causes there to be an extra add instruction) which I need to look into.

It looks like the machine combiner thing is a general problem with the AArch64 patterns not preserving MIFlags. I'll look into it.

The non-essential patterns are now D118485, D118487, D118489. There were also patterns involving load then scvtf/ucvft where it's not clear where they're tested and I haven't been able to trigger with a quick test, so I may just drop those.

Remove non-essential indexed mul/mla patterns that I missed in the last version.

Removed patterns that aren't strictly required for isel, I'll create new patches for those.

I'll split off the parts that are purely patterns into separate patches.

The other parts of this have been split off into D118257, D118258, and D118259. I've also added some extra testing, as the clang test aarch64-neon-intrinsics-constrained wasn't actually testing all of the changes here.

Adjusted the aarch64-v8.2a-fp16-intrinsics-constrained.c test so it can be un-XFAILed, and also adjusted some formatting.

Ping. I've also uploaded D117795 for fixes related to vector instructions.

I need to look at and un-xfail test/CodeGen/aarch64-v8.2a-fp16-intrinsics-constrained.c.

Added some more addOperationAction lines to fix failures in tests. However looking at the tests there's some XFAILed tests that still fail due to more work needing to be done on handling of vector types. I'll do that in a separate patch.

I'm looking at the Clang.CodeGen::aarch64-neon-scalar-x-indexed-elem-constrained.c failure, and it looks like there are other constrained fp tests that are currently xfailed but maybe should actually pass with this patch.

Adjusted based on review comments.