LGTM.
Since we are opting for a definition of reassoc that is not a superset of the other flags, it might be worth seeing if transforms related to arcp and afn are similarly affected.

LGTM

Ping @scanon to comment on whether the exception vs. fold-ability logic seems correct.

Patch updated - no logic changes from earlier rev, but:

1. Make code comment more extensive (I'm speculating that this version is better than what I had before. If so, I can update the SDAG comment too; if not, I can paste in the existing comment from SDAG.)
2. Use KnownBits.insertBits() to reduce code.

In code that I've looked at (mostly C compiled with -ffast-math), we always have contract when we have reassoc, so I don't see much practical difference.
Can you explain more how we could benefit from this change - in the example in the description, we would have 4 instructions rather than 3 if we use FMA - is that better?
We should duplicate (instead of edit) at least a few of the tests, so we can verify that the existing tests do not form FMA now. That could also be used to show an advantage from not forming FMA.

I don't have any real basis to say if this step is good. It would help to point to or show an example where we will eventually win from this change {+ the inverse} + a difference in inlining.
Seems like a potentially large scope change, so post to llvm-dev to see if anyone else has experience/opinions?

In D104472#2825125, @lebedev.ri wrote:

Would it please be possible to either enhance comments, or port more comments from the SelectionDAG::computeKnownBits()?
It appears to match that original implementation, and seems correct, but it is hard to read/get through.

Please see D104383 for an update to regular FP instruction simplification.

@lebedev.ri @RKSimon - any more comments?

LGTM, but let's see if there are any more comments or concerns.

In D103788#2813373, @datta.nagraj wrote:

Hi @spatel Sir, doesn't https://alive2.llvm.org/ce/z/89_wJb prove that this works for even type smaller than log2 of the wide type ? I can add the same test to the unit test, but I am in doubt whether to add it as a check, since the example here proves that it works for difference of bitwidth of more than log 2 as well. I tested with 63, 2 sizes as well, and that works too. Please suggest if we require to add the log2 check, since these are working fine from the above examples.

In D103788#2812375, @datta.nagraj wrote:

Removed the hard cut off check. Please review Sir.

Patch updated:
Make the bailout more general and try to explain the problem pattern in a code comment.

In D104063#2811595, @lebedev.ri wrote:

And what happens when there's more than one PHI node in the block?

In D103788#2810814, @datta.nagraj wrote:

In D103788#2810722, @lebedev.ri wrote:

If we look at the sequence with trunc, then preconditions are different.
I'm not sure if we have *some* problematic combination of src bitwidth and bitwidth increase,
but the hard cut-off that is currently there is not correct.

LGTM

In rGd69c4372bfbe81961160a4e6cb238fb53a279515#1003459, @DavidSpickett wrote:

+1 to limiting it to new pass manager. (good spot btw, I was very confused why this was failing for me)

You get a different order of alloca statements when using the legacy PM.

In D103788#2810167, @lebedev.ri wrote:

In D103788#2810074, @datta.nagraj wrote:

@lebedev.ri Sir, but if we don't take trunc into consideration, then how are we optimizing this?
Earlier it was 2 insts (zext - ctlz), and now its 3 insts(ctlz - add - zext). I agree that the ctlz , add are done on a lower datatype.
If we consider trunc as well, then we can convert 3 insts (zext - ctlz - trunc) to 2 insts (ctlz - add).
Shouldn't we do this opt only when the trunc is present?

In general - yes, in instcombine we should not increase the instruction count,
however as it was already hinted by @spatel, this seems like a rare edge case
where we should be okay with that. (unless @spatel disagrees?)

But would it be better to push this first since it is an extension to the existing functionality, then add the changes for constrained ops on top of this?

I pushed a minimal fix (intersect 'nsz'):
d2012d965d60

In D93818#2804522, @aqjune wrote:

Hi all,

Before diving into further updates in InstCombine (D94380 and D93817), what about pinning down this LangRef update first & letting people know via llvm-dev mail?

Clearly, we're going to need to split this up, but it's not my highest priority, so marking for revision.

LGTM

In D103169#2797205, @kpn wrote:

I could split this up on the fadd/fsub/fmul/etc axis and only handle constrained fadd, for example. Would that be helpful? Your current thoughts, @spatel?

In D102574#2791437, @vdsered wrote:

@spatel you mentioned one more optimization with sext that we miss because of too strict use-constraint here. I'll create another patch for that. I think, it's going to be the last one. I don't know any other transformations for mul/fmul that would benefit from the new method.

In D103617#2796286, @lebedev.ri wrote:

As per 5a654bfeab588715fa6d266a7789484850605a18, did you add the test where we'd form trunc?

In D103180#2793718, @CarolineConcatto wrote:

In D103180#2782981, @spatel wrote:

For the test where the index is presumed invalid (i32 -1), is that enforced somehow? Is there a hard limit somewhere that says i32 0xffffffff must be invalid?

I think the reason it says is invalid is because of the test:
uge(ValSVTy->getMinNumElements() -> unsigned greater or equal