This is an extension of a transform that tries to produce positive floating-point constants to improve canonicalization (and hopefully lead to more reassociation and CSE).
The original patches were:
D4904
D5363 (rL221721)
But as the test diffs show, these were limited to basic patterns by walking from an instruction to its single user rather than recursively moving up the def-use sequence. No fast-math is required here because we're only rearranging implicit FP negations in intermediate ops.
A motivating bug is:
https://bugs.llvm.org/show_bug.cgi?id=32939
...but unfortunately the transform in that example gets inverted in the backend, so we end up with the same code. I'll investigate that case as a follow-up, but I think the changes here can be viewed as an independent improvement.
How about in place of the assert, logic to bypass candidates that meet these constraints. It should not happen given how the candidate list is built, however this would ensure if something did get in we would not process it for release builds.