Overall I think that this looks fine to me as well.
I had a couple of minor comments and you may decide that you don't need to do either one so if that's the case just mention why in a comment and I will approve the patch.

Updated test case to include another thread local value.
Updated the code to include all of the thread local flags.

Overall I think that this patch makes sense to me. A few minor things:

1. I think that there are some changes that are nice improvements but aren't really part of the kill flags fix. This is already a fairly large patch and removing these little fixes might make the patch clearer and easier to read. They can be made before or after with a (or several) NFC change(s).
2. I know this is an older patch and I apologize for taking so long to look at it. When I tried to rebase this patch to the Top of main I realized that I had to add a couple more addRegToUpdate in order to get it working. This isn't an issue with the patch it's just that new changes to PPCMIPeephole will require additions or addRegToUpdate.
3. Is there any way to provide an error or warning for the future when more peephole optimizations are added and for whatever reason the developer forgets to call addRegToUpdate? There may not be a way to do this and that's fine. I'm more curious.

I realize that a lot of test cases have changed but it would be good to add the test case that is specific to this opportunity where the copy is removed.

Split the global TOC entries into Local and External Linkage.

Fixed a couple of spacing issues that I missed when I put the patch up.

@luismarques
Hi,
It looks like your patch broke our build bot on AIX:
https://lab.llvm.org/buildbot/#/builders/214/builds/6115

Rebased to top of trunk.

@chelfi
It looks like this changeset has broken one of the bots on PowerPC.
https://lab.llvm.org/buildbot/#/builders/57

Added a comment to the test case.
Rebased to top of trunk.

Overall I think this patch looks great.

Removed one line of the test that was not required.

Rebased to top of main branch.

LGTM

In D136335#3985562, @haowei wrote:

Test "DebugInfo/assignment-tracking/X86/remove-undef-fragment.ll" is failing on Fuchsia's Linux ARM64 Clang builder as well. Error message:

I've made the test X86 only to allow time for this to be investigated.
34a3259fab86aaa1a20224e08849775f3593e6a3
This should help bring the bots back to green in the meantime.

It looks like the test test/DebugInfo/assignment-tracking/X86/remove-undef-fragment.ll fails on multiple PPC bots.
https://lab.llvm.org/buildbot/#/builders/214/builds/4756
https://lab.llvm.org/buildbot/#/builders/231/builds/6006
https://lab.llvm.org/buildbot/#/builders/121/builds/26032

Silly question:
Can we now get rid of CC_PPC64_ELF_FIS completely?

I would like to address the following comment because it is not at all obvious why I decided not to go with this approach.

This looks wrong. This will produce a pair of 32-bit single precision values in the FP portion of the VSX register. What you want is a 64-bit double precision value in each doubleword.
Don't forget that single precision values on PPC are in registers as double precison but rounded to single precision (i.e. a double precision representation of a single precision value).
I think you should use scalar instructions for scalar values (xscvsxdsp, xscvsxddp).

Removed unnecessary whitespace change.

Fixed the patch and a number of test cases.

I'm going to commandeer this patch and rebase it to see if I can revive it.

There are some tests failing with this patch. I'm looking into them now...

In D138844#3955932, @nemanjai wrote:

Do we already handle vector constants that are splats (i.e. { 1.0f, 1.0f, 1.0f, 1.0f } or { 3.0, 3.0 })? If not, do we plan to?

Moved the constant materialization to the td file.

Thank you for fixing this!
LGTM.

Thank you for fixing this.
I do have a couple of comments related to the fix.

Forgot to do a clang-format.
Updated patch with that.

Rebased to top of main branch.

Thank you for fixing that last test!
LGTM.

Sorry, I know that I had approved this before but it seems that the test p10-splatImm32-undef.ll starts failing with this patch.
It may just be that the test needs to be updated but please make sure that is all it is.

I think this looks good.
Thank you for addressing the comments!

Fixed some spacing and a couple of comments.

Other than a very minor nit I think this LGTM.

Moved the include location for PPCInstrFutureMMA.td.

Rebased patch to top of main branch.

Thank you for your patience and sorry it took me so long to get to this.

Rebased patch to top of main and addressed a couple of nits.

nit: Fixed some spacing.

Rebased to top of main branch.

Thank you both for looking at this patch.
Looking at the comments I feel like I made an incorrect assumption about NULL pointers in this case and I'm just going to abandon this patch.

Sorry that this took a few days.
Removed the code from LICM.
Added a test for the loop strength reduction. The test shows simpler code when
the guard for the NULL is added. However, there may be other tests where the
reverse is true.

This is better than what I initially tried to do in D133426.
LGTM

In D133426#3774603, @nikic wrote:

Please add some tests for the new conditions.