Make @fastmath aware of Base.literal_pow

[ajkeller34]

as Base.literal_pow(Base.FastMath.pow_fast, x, Val{p}).

Thanks to PRs #20530 and #20889, exponentiation of a dimensionful quantity can be type-stable in some important circumstances. However, because macro expansion occurs before the Val lowering happens, @fastmath x^2 cannot be type-stable for dimensionful quantities, whereas x^2 could be. This is because @fastmath x^2 is macro-expanded to Base.FastMath.pow_fast(x,2) and so we can never catch the ^ symbol. See the tests I added to get an idea of how this works.

Provided the premise of this PR isn't flawed somehow, it would probably good to have someone more familiar with julia_syntax.scm see if there’s a better way to implement this change. Because I tie into the mechanism introduced in #20889 I don't expect any "surprising behaviors" to be introduced here, though I haven't checked to see if there are any performance implications.

[tkelman]

dunno if nanosoldier will really notice lowering performance, but may as well trigger @nanosoldier runbenchmarks(ALL, vs = ":master")

[nanosoldier]

Your benchmark job has completed - possible performance regressions were detected. A full report can be found here. cc @jrevels

[TotalVerb]

It would make more sense to do this in the @fastmath macro than in lowering.

[StefanKarpinski]

It would make more sense to do this in the @fastmath macro than in lowering.

100% – we can't go around having special cases for every macro anyone might need special behavior for in the parser.

[ajkeller34]

Yeah, good point, I'll see what I can do.

[ajkeller34]

Updated, this approach seems much better and obvious in retrospect. I guess this is what happens when you learn about how lisp works for the first time and get a little too exuberant.

[KristofferC]

Let's rerun CI and Nanosoldier and try get this merged.

[KristofferC]

@nanosoldier runbenchmarks(ALL, vs = ":master")

[stevengj]

It would be nice to have @fastmath convert x^literal to an optimal chain of multiplications ala #20637, but we can leave that for a future PR.

[nanosoldier]

Something went wrong when running your job:

NanosoldierError: failed to run benchmarks against primary commit: failed process: Process(`sudo cset shield -e su nanosoldier -- -c ./benchscript.sh`, ProcessExited(1)) [1]

Logs and partial data can be found here
cc @ararslan

[KristofferC]

Tests seems to fail now. Is it because the Val optimization is only made to "hardware numbertypes" now?

[ajkeller34]

I updated the PR, squashed, and rebased. fastmath tests passed locally. The problem was because the PR hadn't adopted the new Val(x) syntax from #22475.

[ajkeller34]

@KristofferC want to try triggering nanosoldier again? Looks like the tests passed (travis timed out for likely unrelated reasons).

[ararslan]

Another Nanosoldier run is unlikely to work, Nanosoldier itself is still having problems (unrelated to this PR)

[KristofferC]

I thought it worked a few times yesterday @nanosoldier runbenchmarks(ALL, vs = ":master")

[nanosoldier]

Your benchmark job has completed - possible performance regressions were detected. A full report can be found here. cc @ararslan

[ararslan]

It's been working randomly but failing most of the time

[ajkeller34]

This is ready to merge as far as I can tell. Does anything else need to be done here?

[stevengj]

Bump.

[stevengj]

Any chance of merging this?

[JeffBezanson]

From triage: seems fine, just rebase please.

[stevengj]

Rebased.

[oscardssmith]

The test this PR adds is the one that's failing.

[stevengj]

Interacting badly with #24240, will fix.

[stevengj]

Actually, #24240 already seems to fix this issue in another way — @fastmath x^2 goes to pow_fast(x, Val{2}()) which calls literal_pow by default.

So maybe this can be closed?