[llvm] [InstCombine] Fold tan(x) * cos(x) => sin(x) (PR #136319)

[Andy Kaylor via llvm-commits]

================
@@ -947,6 +947,14 @@ Instruction *InstCombinerImpl::foldFMulReassoc(BinaryOperator &I) {
     return BinaryOperator::CreateFMulFMF(XX, Y, &I);
   }
 
+  // tan(X) * cos(X) -> sin(X)
+  if (match(&I,
----------------
andykaylor wrote:

> This footnote is informative and I don't see how it makes sense to interpret it as a restriction. 

I'm not interpreting it as a restriction necessarily, just as a guideline to what a reasonable and informed user might expect.

> The IR is not a vehicle for directly mapping source constructs onto machine instructions and has to have a freestanding meaning with no concern for how the backend happens to emit it on a particular target

I understand that, but there is also an implicit understanding between the optimizer and front ends. The optimizer can't just expand the way it interprets IR without a corresponding change in the front ends that rely on the current behavior. What you are suggesting here is, IMO, a significant extension to the way the `contract` flag is interpreted, and if we are going to interpret it broadly going forward, I would want to see a corresponding change in clang to stop generating the `contract` flag on function calls when only `-ffp-contract=fast` is specified, and I wouldn't be surprised if other front ends would require a similar adjustment.

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