[llvm] [InstCombine] Extend bitmask mul combine to handle independent operands (PR #142503)

[Jeffrey Byrnes via llvm-commits]

jrbyrnes wrote:

> > Moreover, we still need to do the analysis to check for the conditions of reassociation. Thus, it is somewhat unclear if this change is a net positive.
> 
> I don't think it is necessary to check the specific pattern. As these two muls share the same constant factor, it is always profitable to reassociate the tree. `ReassociatePass` performs the reassociate for add, but not for `or disjoint`: https://godbolt.org/z/TMcYTdd5T It may be better to handle this pattern in `ReassociatePass`.

Sorry, did not see your comment originally.

I think we can extend the reassociation pass to handle cases like https://godbolt.org/z/7vWePe1xK , but I don't think this will be sufficient for my usecase.

The problem is https://github.com/llvm/llvm-project/pull/133139#issuecomment-2773977867

In other words:

%masked = and i32 %val, CONSTANT
%cond = icmp eq i32 %masked, 0
%out = select i1 %cond, i32 0, i32 CONSTANT * FACTOR

is the canonical form of

%masked = and %val, CONSTANT
%out = mul i32 %masked, FACTOR

The premise of the work starting at https://github.com/llvm/llvm-project/pull/136013 is that if we are combining multiple of these forms under an or-disjoint, it is preferable to have a single and->mul. This PR and subsequent PRs (including the PR I'm currently commenting on) have transformed the select form into and->mul given conditions which make the transform unarguably beneficial, however, it is still very much possible that we have the select form.

Thus, to be sufficient for my usecase, reassociation must be able to handle the case where one or more of the leaf forms are and->icmp->select (instead of and->mul). Presently, this is not done even for the add case https://godbolt.org/z/W1YxhrWa9 .

Potentially, we could make this extension to the add case, then extend the or-disjoint to support all forms. However, if possible I would prefer to bring in something along the lines of what this PR is currently doing, potentially to be deleted after we improve reassociation -- this work has already been stalled for some time, and going the reassociation route seems like it would open a whole new body of work.

https://github.com/llvm/llvm-project/pull/142503