Yichao is correct. The `box` intrinsic isn't particularly well named and has a bit of an identity crisis -- if it throws an error, it calls itself `reinterpret`, which is closer to it's real purpose, which is to change the declared type of some bits.
On Thursday, January 14, 2016 at 8:26:39 PM UTC-5, Yichao Yu wrote: > > 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 >
