Lack of constant prop in `nextpow(2, x)`

[tecosaur]

When calling nextpow(2, x), it seems that it's expected that Base._nextpow2 is inlined.

julia/base/intfuncs.jl

Lines 575 to 578 in 4846c3d

	# Special case fast path for x::Integer, a == 2.
	# This is a very common case. Constant prop will make sure that a call site
	# specified as `nextpow(2, x)` will get this special case inlined.
	a == 2 && isa(x, Integer) && return _nextpow2(x)

However, with 1.11 through to nightly, it seems like this may not be the case. I see those lines were written in 2018, and needless to say a lot has changed since then.

julia> npow2constproptest(x) = nextpow(2, x)
npow2constproptest (generic function with 1 method)

julia> @code_native npow2constproptest(1234)
	.file	"npow2constproptest"
	.section	.ltext,"axl",@progbits
	.globl	julia_npow2constproptest_4029   # -- Begin function julia_npow2constproptest_4029
	.p2align	4
	.type	julia_npow2constproptest_4029,@function
julia_npow2constproptest_4029:          # @julia_npow2constproptest_4029
; Function Signature: npow2constproptest(Int64)
; ┌ @ REPL[4]:1 within `npow2constproptest`
# %bb.0:                                # %top
	#DEBUG_VALUE: npow2constproptest:x <- $rdi
	push	rbp
	mov	rbp, rsp
	mov	rsi, rdi
	movabs	rax, offset j_nextpow_4031
	mov	edi, 2
	call	rax
	pop	rbp
	ret
.Lfunc_end0:
	.size	julia_npow2constproptest_4029, .Lfunc_end0-julia_npow2constproptest_4029
; └
                                        # -- End function

Is a Base.@constprop :aggressive annotation needed here? From a quick check, it seems to help. There does seem to be some extra overhead compared to _nextpow2 though. Perhaps I'm being overly optimistic, but I hoped that npow2constproptest would compile to the same instructions as _nextpow2, and even with aggressive constant prop that doesn't seem to be the case.

[nsajko]

Quite possibly related PR: #49672

[giordano]

Quite possibly related PR: #49672

That PR doesn't seem to help:

julia> @eval Base function nextpow(a::T, x::Real) where T <: Real
           x <= 0 && throw(DomainError(x, "`x` must be positive."))
           # Special case fast path for x::Integer, a == 2.
           # This is a very common case. Constant prop will make sure that a call site
           # specified as `nextpow(2, x)` will get this special case inlined.
           a == 2 && isa(x, Integer) && return T(_nextpow2(x))
           a <= 1 && throw(DomainError(a, "`a` must be greater than 1."))
           x <= 1 && return one(a)
           n = ceil(Integer,log(a, x))
           # round-off error of log can go either direction, so need some checks
           p = a^(n-1)
           hastypemax(typeof(p)) && x > typemax(p) &&
               throw(DomainError(x,"argument is beyond the range of type of the base"))
           p >= x && return p
           wp = a^n
           wp > p || throw(OverflowError("result is beyond the range of type of the base"))
           wp >= x && return wp
           wwp = a^(n+1)
           wwp > wp || throw(OverflowError("result is beyond the range of type of the base"))
           return wwp
       end
nextpow (generic function with 1 method)

julia> npow2constproptest(x) = nextpow(2, x)
npow2constproptest (generic function with 1 method)

julia> @code_llvm npow2constproptest(1234)

; Function Signature: npow2constproptest(Int64)
;  @ REPL[2]:1 within `npow2constproptest`
define i64 @julia_npow2constproptest_1580(i64 signext %"x::Int64") local_unnamed_addr #0 {
top:
  %0 = call i64 @j_nextpow_1582(i64 signext 2, i64 signext %"x::Int64")
  ret i64 %0
}

Is a Base.@constprop :aggressive annotation needed here? From a quick check, it seems to help. There does seem to be some extra overhead compared to _nextpow2 though.

I believe the extra overhead is due to the error thrown at

julia/base/intfuncs.jl

Line 574 in 4846c3d

x <= 0 && throw(DomainError(x, "`x` must be positive."))

which depends on x and can't be elided. Base._nextpow2 happily returns something for non-positive values

julia> Base._nextpow2(0)
0

julia> Base._nextpow2(-5)
-8

[tecosaur]

Given that there's a ~4x performance difference between nextpow and Base._nextpow2 (which often doesn't matter, but can find itself in a hot loop), is there much that can be done about that?

[giordano]

Given that there's a ~4x performance difference between nextpow and Base._nextpow2 (which often doesn't matter, but can find itself in a hot loop)

How did you measure that?

julia> using BenchmarkTools

julia> @btime Base._nextpow2(1025);
  1.167 ns (0 allocations: 0 bytes)

julia> @btime Base.nextpow(2, 1025);
  1.166 ns (0 allocations: 0 bytes)

is there much that can be done about that?

You mean besides Base.@constprop :aggressive? That looks ok-ish to me, but I'm not an effects lawyer so I really don't know whether it's sensible to force it, but in nextpow x is documented to be strictly positive, so you'll have to live with throwing the error.

[JeffBezanson]

If you put @inline on the call site, you can see that it does get const prop'd and _nextpow2 is inlined into nextpow, and the whole result is still inlineable. Without @inline though nextpow mysteriously isn't inlined into its caller.

[tecosaur]

How did you measure that?

On one of my systems with nightly Julia:

julia> @btime Base._nextpow2(287);
  1.202 ns (0 allocations: 0 bytes)

julia> @btime nextpow($2, 287);
  5.450 ns (0 allocations: 0 bytes)