In D63609#1556071, @spatel wrote:

Answering myself - doesn't look like anything has changed since:
D62444 / rL361788

Add two more tests (X86/propagate_ir_flags.ll).

LGTM, assuming the test writer was not intentionally playing games with the fabs(...) calls.

Ping*2.

Remove unintentional changes. Also fix up a poor naming choice.

Correct comment. Should be 'nnan', not 'nnan and nsz'.

In D63405#1546701, @spatel wrote:

But there's a separate question that is raised here: why is it legal to convert fneg to fsub -0.0? That loosens the IEEE requirement when dealing with a NAN. I'd think this should be legalized by converting to integer and flipping the sign bit (xor).
ping @cameron.mcinally

LGTM

LGTM

Ping.

Add context to Diff.

In D62629#1536451, @spatel wrote:

In D62629#1536402, @cameron.mcinally wrote:

Check hasOneUse() before performing combine.

That's an independent fix and needs a test?

Ping.

In D62629#1522985, @cameron.mcinally wrote:

Also note that this change will require UnaryOperator::CreateFNegFMF(...) from D62521, so cannot be committed until that is complete.

Check hasOneUse() before performing combine.

Update llvm_unreachable strings...

Good compromise. LGTM.

LGTM, although I'm not fluent in AMDGPU assembly. You may want to wait a little while to see if an expert comes along.

Ping...

Ping...

This LGTM, with one clarification inline...

I haven't enabled handling of undefs in build vector - but can anyone think of a reason that I shouldn't?