On Thu, Jan 14, 2016 at 7:48 PM, Spencer Russell <[email protected]> wrote: > Is there a way to check for whether values are getting boxed/unboxed short > of looking at the llvm code? As an example, here’s a simple function that I > wouldn’t expect to need any boxes: > > julia> function isnullptr{T}(x::Ptr{T}) > x == Ptr{T}(0) > end > isnullptr (generic function with 1 method) > > But when I look at it with `code_warntype` it shows a comparison between the > boxed versions of the pointers: > > julia> code_warntype(isnullptr, (Ptr{Void}, )) > Variables: > x::Ptr{Void} > > Body: > begin # none, line 2: > return (Base.box)(UInt64,x::Ptr{Void}) === > (Base.box)(UInt64,(Base.box)(Ptr{Void},0))::Bool > end::Bool > > But by the time the code gets generated I can rest easy that all is well: > > julia> code_llvm(isnullptr, (Ptr{Void}, )) > > define i1 @julia_isnullptr_21821(i8*) { > top: > %1 = icmp eq i8* %0, null > ret i1 %1 > } > > So in this case the end result was what I expected, but I’m currently trying > to debug some problems with a larger chunk of code and am not very > llmv-literate, so I’m wondering if there’s another way to check. > > Interestingly, a more general zero-checker: iszero{T}(x::T) = x == T(0) > doesn’t show boxing in the code_warntype output if T is an Int, but does if > it's Ptr{Void} type, so maybe this is somewhat pointer-specific? > Unfortunately the code I’m looking at does a lot of pointer wrangling.
Ignore the `Base.box` in the typed ast. I don't think they will cause heap allocation unless there's type instability. > > Thanks, > Spencer
