Performance regression with niche optimization

[mikebenfield]

After PR #94075 for more niche optimizations was merged, there were some performance regressions.

Some performance regressions are possibly just due to the extra arithmetic and branch or cmov required when getting a discriminant out of a tag. But notably when compiling syn, the regression is largely due to extra time in LLVM_lto_optimize.

It would be nice to understand this better, and ideally do something about it.

[Rageking8]

@rustbot label +T-compiler +regression-untriaged

[nnethercote]

#102035 is a related example, where increased use of niche-filling causes some small but widespread instruction count regressions.

[apiraino]

WG-prioritization assigning priority (Zulip discussion).

@rustbot label -I-prioritize +P-medium

[mikebenfield]

A little more data:

I did some local testing using the "Self profile" mode of the perf tool, compiling syn for the Opt profile and scenario IncrPatched (the same profile at the link above). I compared a recent master to a modifed master turning off niche optimizations when more than one variant has data.

The results I get locally make a lot more sense to me. The linked data shows the LLVM_lto_optimize step taking 42% of total time, which seems odd. Locally it takes only around 0.1% of total time. Instead, a lot of time is taken in various particular LLVM passes, which also seems to be where all/most of the increase comes in with more niche optimizations. Notably InstCombinePass.