An optional MPFR dependency would also be pretty painful. I expect it will
frequently be missing and will not be exercised by most buildbots.IMO if constant folding of transcendental functions makes a significant
difference for your program, you likely are doing something strange
already. I don’t think it matters much for a lot of use cases, so having
an optional dependency for this seems to be fine.
I think that if transcendental functions are sufficiently unimportant, we shouldn’t support them at all. We should have consistent behavior rather than ending up with nearly impossible to triage issues because one person’s Clang used MPFR and the other didn’t.
While I think the optimizer should be able to constant fold transcendentals as a matter of core competency, I don’t have very strong opinions about it for the reasons you cite – I don’t have use cases.
Note that the
non-transcendental functions are quite a different deal, especially
reasonable well behaving functions like log and exp.
Agreed, and I feel very strongly that we should support both log and exp, and it has no business being optional.
But clearly the right way to do this is to start from the bottom and work our way up. We should add the easiest ones first and incrementally add support. I particularly like the suggestions from Hal about how to make this a tractable engineering task.