Documentation
¶
Overview ¶
Command truncspill reports where Go 1.27's loong64 back end spills a float-to-integer conversion in a way that can reach the stack slots next to it -- the shape of golang.org/issue/81000.
On loong64 the rule
(Cvt64Fto32 x) => (TRUNCDW x)
leaves an INTEGER result in a floating-point register, because TRUNCDW is declared `reg: fp11`. Spilling such a value therefore emits an 8-byte MOVD. CL 820040 fixes it by wrapping the conversions in MOVWfpgp/MOVVfpgp, so a toolchain whose output contains no MOV[WV]fpgp does not carry the fix.
An occurrence is NOT a defect. An 8-byte store into its own 8-aligned 8-byte slot writes exactly its own value. It corrupts only when a live neighbour sits inside those eight bytes, which shows as a positive stride below 8 between two spill offsets in one frame, or as an offset that is not 8-aligned. That distinction is the whole point of this command: measured on go-gfx/gfx `./color`, go1.26.4 -- which PASSES on loong64 -- also spills, twice, onto -88 and -96; go1.27.1 -- which FAILS -- spills onto -145..-140 and -275,-276.
Source Files