Float Literal Support

[njriasan]

---

Feature request Float Literal Type

I'd like to see support for a Float Literal type, similar to the Integer Literal and Boolean Literal types that currently exist.
The main motivations for this use case would be to situations where users provide floats to APIs that require constants for typings (and in practice accept integers or floats) or to support the option to avoid runtime checks for common cases with users tend to provide literals (i.e. numpy.quantile https://numpy.org/doc/stable/reference/generated/numpy.quantile.html).

I'm happy to provide this feature in a PR myself.

[sklam]

Interesting. Can you tell me how it will be advantageous for the compiler to know that literal value of the float? I am assuming it will be for the q, 2nd arg of np.quantile.

[njriasan]

Yes I mean for q. Since I think the most common use case is providing literals for q (float, list, etc), knowing common values of q (0.0, 0.5, 1.0) can allow generating specialized code (min, median, max) at compile time. Currently I believe this check is done at runtime, which results in extra control flow that could be avoided. In addition, from what I can tell there is no optimization that converts quantile to median right now.

This is just one example where I believe it could be useful, but in general I think Literal Floats could be used to push simple runtime checks into compile time, which when used with caching may prove to be beneficial for overall performance.

[njriasan]

To clarify, I'm not proposing a PR to provide this change in np.quantile, but Float Literal support enable making this decision (if warranted) in the future. Again I'm happy to contribute a PR for float literals.

[sklam]

Summarizing important notes from today's Numba meeting:

Overspecialization concern

Concerns that Numba will overspecialize and significantly increase compile time for a lot of the code given that float literals are common.

Let LLVM do the work

Runtime benefits can be achieved without float literal in Numba. Consider

@jit
def foo(val):
    if val == 1.0:   # specialize on float value being 1
        return loopy_code_optimize_for_one(val)  # code containing loops
    else:
        return loopy_code_generic(val)  # code containing loops

@jit
def user():
    foo(1.0)   # uses with float literal

Even without recognizing the float literal in Numba, LLVM (Numba's backend) will still see the literal value and elide the comparison in foo() when it is inlined.

In other places, literal values are needed only because the typing, particularly the return type, is dependent on the argument values; e.g. axis argument in many numpy functions. In those functions, literal values are an requirement.

Our current recommendation is to reserve the use of literals to cases where compilation cannot succeed unless a literal value is provided. Runtime performance benefit is likely achievable via LLVM optimization without any literal specialization within Numba.

[njriasan]

Hi @sklam. I think the overspecialization concern is a solid reason for not proceeding with this feature. Thank you for considering it.

[ehsantn]

prefer_literal is off by default for overloads, and only some array methods turn it on. Is the concern about overspecialization of those array methods? Am I missing some other cases?

Maybe prefer_literal can be a list to specify exactly what arguments are preferred to be a literal.