`code_native` generates different code with `dump_module=true` and `dump_module=false`

[dzhang314]

According to the documentation for code_native, the flag dump_module::Bool is only supposed to affect metadata.

If dump_module is false, do not print metadata such as rodata or directives.

However, I observe different actual assembly code generated with dump_module=true and dump_module=false. As a very simple example:

   _       _ _(_)_     |  Documentation: https://docs.julialang.org
  (_)     | (_) (_)    |
   _ _   _| |_  __ _   |  Type "?" for help, "]?" for Pkg help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 1.10.9 (2025-03-10)
 _/ |\__'_|_|_|\__'_|  |  Official https://julialang.org/ release
|__/                   |

julia> code_native(+, (Float64, Float64); dump_module=false)
	.text
; ┌ @ float.jl:409 within `+`
	push	rbp
	mov	rbp, rsp
	mov	rax, qword ptr [r13 + 16]
	mov	rax, qword ptr [rax + 16]
	mov	rax, qword ptr [rax]
	addsd	xmm0, xmm1
	pop	rbp
	ret
; └
; ┌ @ float.jl:409 within `<invalid>`
	nop	word ptr cs:[rax + rax]
; └

julia> code_native(+, (Float64, Float64); dump_module=true)
	.text
	.file	"+"
	.globl	"julia_+_72"                    # -- Begin function julia_+_72
	.p2align	4, 0x90
	.type	"julia_+_72",@function
"julia_+_72":                           # @"julia_+_72"
; ┌ @ float.jl:409 within `+`
# %bb.0:                                # %top
	push	rbp
	mov	rbp, rsp
	vaddsd	xmm0, xmm0, xmm1
	pop	rbp
	ret
.Lfunc_end0:
	.size	"julia_+_72", .Lfunc_end0-"julia_+_72"
; └
                                        # -- End function
	.section	".note.GNU-stack","",@progbits

The first version has a three-level pointer chase that's absent from the second version! In addition, note the use of the two-argument form addsd xmm0, xmm1 compared to the three-argument form vaddsd xmm0, xmm0, xmm1 and the presence of the extra nop instruction. What is going on here?

[dzhang314]

For reference, I'm on Julia 1.10.9 on Linux using an AMD Ryzen 9 9950X CPU. Full versioninfo(; verbose=true) below:

Julia Version 1.10.9
Commit 5595d20a287 (2025-03-10 12:51 UTC)
Build Info:
  Official https://julialang.org/ release
Platform Info:
  OS: Linux (x86_64-linux-gnu)
      Linux Mint 22.1
  uname: Linux 6.8.0-55-generic #57-Ubuntu SMP PREEMPT_DYNAMIC Wed Feb 12 23:42:21 UTC 2025 x86_64 x86_64
  CPU: AMD Ryzen 9 9950X 16-Core Processor: 
                 speed         user         nice          sys         idle          irq
       #1-32  5621 MHz        413 s          0 s        150 s      60911 s          0 s
  Memory: 62.39461898803711 GB (59866.69921875 MB free)
  Uptime: 193.15 sec
  Load Avg:  0.53  0.21  0.07
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-15.0.7 (ORCJIT, generic)
Threads: 1 default, 0 interactive, 1 GC (on 32 virtual cores)
Environment:
  XDG_SESSION_PATH = /org/freedesktop/DisplayManager/Session0
  HOME = /home/dkzhang
  XDG_SEAT_PATH = /org/freedesktop/DisplayManager/Seat0
  TERM = xterm-256color
  PATH = /home/dkzhang/.juliaup/bin:/home/dkzhang/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/home/dkzhang/.local/bin

[vtjnash]

It also implies the raw=true flag, for more accurate instruction printing. The same flag can be optionally enabled for dump_module=true for more accurate printing then also, but it tends to not be as useful in that mode.

[dzhang314]

@vtjnash In that case, why doesn't raw=true or raw=false have an effect in the following example?

julia> code_native(+, (Float64, Float64); dump_module=false, raw=false)
	.text
; ┌ @ float.jl:409 within `+`
	push	rbp
	mov	rbp, rsp
	mov	rax, qword ptr [r13 + 16]
	mov	rax, qword ptr [rax + 16]
	mov	rax, qword ptr [rax]
	addsd	xmm0, xmm1
	pop	rbp
	ret
; └
; ┌ @ float.jl:409 within `<invalid>`
	nop	word ptr cs:[rax + rax]
; └

julia> code_native(+, (Float64, Float64); dump_module=false, raw=true)
	.text
; ┌ @ float.jl:409 within `+`
	push	rbp
	mov	rbp, rsp
	mov	rax, qword ptr [r13 + 16]
	mov	rax, qword ptr [rax + 16]
	mov	rax, qword ptr [rax]
	addsd	xmm0, xmm1
	pop	rbp
	ret
; └
; ┌ @ float.jl:409 within `<invalid>`
	nop	word ptr cs:[rax + rax]
; └

[vtjnash]

dump_module=false has no distinction between "raw" and not raw: they are the same

[dzhang314]

Yes, but why is that the case? Is it not possible to implement safepoint elision for dump_module=false mode? In either case, this behavior should be documented. I would be happy to submit a documentation PR but I need to understand what exactly is different between these code paths so I can accurately document it.

More importantly, why does raw=true or raw=false affect instruction selection (addsd vs vaddsd)? The docs say it only "elides uninteresting instructions":

If raw is false, uninteresting instructions (like the safepoint function prologue) are elided.

The fact that the instruction selection works differently between these modes is extremely alarming to me as a Julia user. It implies that at least one mode is lying to me about what actually runs when I execute x::Float64 + y::Float64. Of course, I realize there is no single answer to "what actually runs" because it depends on how the optimizer/auto-vectorizer/etc. interacts with the surrounding code at compilation time. But this fact needs to be documented.

What is different about the raw=true and raw=false compilation pathways (and, for that matter, the dump_module=true and dump_module=false pathways) to create observably different assembly?