concrete-eval: Use concrete eval information even if the result is big

[Keno]

When we originally implemented concrete-eval, we decided not to create Const lattice elements for constants that are too large, on the fear that these would end up in the IR and blowing up the size. Now that we have some experience with this, I think that decision was incorrect for several reasons:

1. We've already performed the concrete evaluation (and allocated the big object), so we're just throwing away precision here that we could have otherwise used (Although if the call result is unused, we probably shouldn't do concrete eval at all - see Don't attempt concrete eval if there's no information to be gained #46774).
2. There's a number of other places in the compiler where we read large values into Const. Unless we add these kinds of check there too, we need to have appropriate guards in the optimizer and the cache anyway, to prevent the IR size blowup.
3. It turns out that throwing away this precision actually causes significant performance problems for code that is just over the line. Consider for example a lookup of a small struct inside a large, multi-level constant structure. The final result might be quite tiny, but if we refuse to propagate the intermediate levels, we might end up doing an (expensive) full-constprop when propagating the constant information could have given us a much cheaper concrete evaluation.

This commit simply removes that check. If we see any regressions as a result of this, we should see if there are additional guards needed in the optimizer.

[aviatesk]

Consider for example a lookup of a small struct inside a large, multi-level constant structure. The final result might be quite tiny, but if we refuse to propagate the intermediate levels, we might end up doing an (expensive) full-constprop when propagating the constant information could have given us a much cheaper concrete evaluation.

Maybe we can have a benchmark target for this kind of case in BaseBenchmarks.jl?
This PR itself LGTM.

[Keno]

Maybe we can have a benchmark target for this kind of case in BaseBenchmarks.jl?

Yes, should be reasonably to do. Just build a trie or a heap out of tuples or something.

[aviatesk]

Yes, should be reasonably to do. Just build a trie or a heap out of tuples or something.

I will try to come up with one. For the meanwhile, let's try the other benchmarks and merge this if there are no apparent regressions.

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

[nanosoldier]

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

[aviatesk]

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

[nanosoldier]

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

[Keno]

Nanosolider is fine here right, since "allinference" went down it actually got faster, optimization time for this one frame going up would make sense if things became more inlineable and optimization has to do more work, but since allinference got faster on the same benchmark, inference overall would be faster.

[aviatesk]

Sounds reasonable. Let's get this merged.

[vtjnash]

I am hoping someday we can get rid of this arbitrary size cutoff entirely, and just do something simple like:

is_inlineable_constant(x) = (!ismutable(x) && datatype_pointerfree(typeof(x))) || x isa Type || x isa Symbol

this avoids embedding pointers to random bits of mutable memory, but otherwise drops the random size cut-off