add a lattice element type for constants in inference

[JeffBezanson]

This incorporates a bit of constant propagation into type inference, giving better type information and removing some special-case code we'd started accumulating.

Todo:

• Get tests passing, make sure no performance or type info regressions
• Take advantage of the extra information in more t-functions

[JeffBezanson]

runbenchmarks(ALL, vs = "JuliaLang/julia:master")

[nanosoldier]

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

[tkelman]

does this reserve this unicode operator so packages can no longer use it?

[vtjnash]

yes, but only for packages that start with import Core.Inference.⊑ :P

[JeffBezanson]

Anybody have opinions on the benchmark results? Worst number is 2.67x allocations on a sorting benchmark, which I can't reproduce locally. Another one has 0.03x allocations, which is pretty implausible.

[KristofferC]

I've seen all of those benchmarks in previous reports. They seem to be a bit wonky.

[vtjnash]

that does look strange. i think you may need to manually review the core.jl tests and the benchmarks, to make sure that constant propagation won't change what's being tested.

[JeffBezanson]

I think we'll only really need to worry if and when we can infer the type of Any[x][1].

[vtjnash]

just browsing at random: the test for issue #4688, may be assuming that true == true is not inferrable, the test for issue #10281 appears to assume that if false is not DCE before codegen.

[JeffBezanson]

The test for #4688 looks bit-rotted at this point; it seems to be related to whether x was a captured variable in the old implementation of closures.

For #10281, we have been able to infer if false for quite some time. In fact the test might be depending on that.

[jrevels]

All the benchmark changes reported here are known to be noisy (including the weird allocation counts reported by the sorting benchmarks). If they can't be reproduced locally, then you can chalk it up to noise.

[vtjnash]

i think you would want s = s here, to preserve the type identity

[JeffBezanson]

Comments addressed.

[vtjnash]

hm, github isn't showing quite what I hoped for a diff here – i was attempting to push the merge commit here in an attempt to test it before submitting it to master

[tkelman]

should only be 2 commits here, ee7f643 and its parent 10e9ef5, right? just force push the later one of those back over this branch?

[Keno]

@JeffBezanson: Any chance you could make the following infer Val{4} as the argument type to bar?

function foo(x)
    if x == 4
        bar(Val{x}())
    end
end