aboutsummaryrefslogtreecommitdiff
path: root/src/cmd/internal/obj
AgeCommit message (Collapse)Author
35 hourscmd/asm, cmd/internal/obj/arm64: support memory with MUL VL imm offsetJunyang Shao
This CL is generated by CL 765440. This CL supports this addressing pattern: (VL*imm)(Reg) (-VL*imm)(Reg) Change-Id: I4d1bab2ef6c4141699a47b28aa14b28cdee6cb3f Reviewed-on: https://go-review.googlesource.com/c/go/+/765420 LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David Chase <drchase@google.com> Commit-Queue: Junyang Shao <shaojunyang@google.com>
35 hourscmd/asm, cmd/internal/obj/arm64: support memory with imm offset in SVEJunyang Shao
This CL is generated by CL 765100 This CL supports this addressing pattern: imm(reg.T) Change-Id: I16789e8e6cf03c4fa225c0fe1bd31dc23c9feb21 Reviewed-on: https://go-review.googlesource.com/c/go/+/765080 Reviewed-by: David Chase <drchase@google.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
35 hourscmd/asm, cmd/internal/obj/arm64: support special operands in SVEJunyang Shao
This CL is generated by CL 764980. This CL supports these new special constants: <prfop>, which Go already support (prefetch modifier) <vl>, which include VLx2 and VLx4, which is the vector length specifier. Change-Id: I831f306a816493c08f3c22786e5360f2a37acf6c Reviewed-on: https://go-review.googlesource.com/c/go/+/765000 LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David Chase <drchase@google.com>
35 hourscmd/asm, cmd/internal/obj/arm64: support memory with extensions in SVEJunyang Shao
This CL is generated by CL 764800. Supported addressing patterns: (Z7.D.SXTW<<2)(Z6.D), where Z6.D is the base, Z7.D is the indices. SXTW/UXTW represents signed/unsigned extension, << represents LSL. Change-Id: Ifc6c47833d5113be7cfe96943d369ab977b3a6ee Reviewed-on: https://go-review.googlesource.com/c/go/+/764780 Reviewed-by: David Chase <drchase@google.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Commit-Queue: Junyang Shao <shaojunyang@google.com>
35 hourscmd/asm, cmd/internal/obj/arm64: support SVE register listsJunyang Shao
This CL adds the register list support for SVE: [Z1.B, Z2.B] [P1.B, P2.B] [Z1.D] [Z1.D, Z2.D, Z3.D] [Z1.D, Z2.D, Z3.D, Z4.D] This CL is generated by CL 763780. Change-Id: I92210097a8a7525a5a53a2dce0b7652397275dd6 Reviewed-on: https://go-review.googlesource.com/c/go/+/763820 Reviewed-by: David Chase <drchase@google.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
35 hourscmd/asm, cmd/internal/obj/arm64: add support for immediatesJunyang Shao
This CL supports various immediate operand patterns. ARM designs the immediate to carry significant semantics, this CL tries to address them as what GNU assembler do, and what the ARM ASL specifies. This CL is generated by CL 763781. Change-Id: I40e2b573f196a947c4f3e55c2be7b8d551471c84 Reviewed-on: https://go-review.googlesource.com/c/go/+/763769 LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David Chase <drchase@google.com> Commit-Queue: Junyang Shao <shaojunyang@google.com>
5 dayscmd/asm, cmd/internal/obj/arm64: support register with index in SVEJunyang Shao
This CL is generated by CL 759800. The new register patterns are (examples): Z1.B[5] Z2[6] P1[7] PN1[8] Change-Id: I5bccc4f1c0474dbd4cd4878bd488f36a7026c7ca Reviewed-on: https://go-review.googlesource.com/c/go/+/759780 Reviewed-by: David Chase <drchase@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
5 dayscmd/asm, cmd/internal/obj/arm64: add GP and SIMD reg support for SVEJunyang Shao
The GP registers and SIMD registers are comforming to the existing Go syntax: they are V or R registers, their widths are specified in the Opcode, the rules to specify them is: - if that instruction only contains one GP or SIMD register: If it's 32-bit GP, then append W to the end of the opcode. If it's 64-bit GP, no changes. If it's SIMD register with BHWD width specification, BHSDQ will just be appended to the end of the opcode. - if it contains multiple GP or SIMD registers, then manual observation found that they are either specified the same width, or they are fixed width. We distinguish them by their first Go ASM operand width. The rule to append suffixes are the same to the single-reg case above. This CL is generated by CL 759280. Change-Id: Icc819cc30dd8fd1609de31ba7bcb4e3ac83c465e Reviewed-on: https://go-review.googlesource.com/c/go/+/759261 Reviewed-by: David Chase <drchase@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
5 dayscmd/internal/obj/loong64: correct instruction encodinglimeidan
Change-Id: I4a9b5d8f7a452cbc6082783723450d8713a04fd9 Reviewed-on: https://go-review.googlesource.com/c/go/+/763940 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Junyang Shao <shaojunyang@google.com> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: abner chenc <chenguoqi@loongson.cn>
7 dayscmd/internal/obj/arm64: add ASIMD cross-lane reduction instructionsAlexander Musman
Add support for ASIMD instructions that reduce a vector to a scalar by operating across all lanes. These use the ASIMDALL encoding class from the ARM architecture specification. Integer cross-lane reductions (.B8, .B16, .H4, .H8, .S4): Signed max/min across lanes: VSMAXV, VSMINV Unsigned max/min across lanes: VUMAXV, VUMINV Floating-point cross-lane reductions (.S4 arrangement): FP max/min across lanes: VFMAXV, VFMINV FP max/min across lanes (NM): VFMAXNMV, VFMINNMV Change-Id: I6af4462d26803dfc7c78db2ad9df4284083e31e8 Reviewed-on: https://go-review.googlesource.com/c/go/+/762202 Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Keith Randall <khr@golang.org> Auto-Submit: Keith Randall <khr@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
7 dayscmd/internal/obj/arm64: add ASIMD miscellaneous unary instructionsAlexander Musman
Add support for ASIMD unary miscellaneous instructions that operate on a single source register. These use the ASIMDMISC encoding class from the ARM architecture specification. These instruction need some validation for arrangement constraints: - VNOT only allows .B8/.B16 arrangements - VCLS/VCLZ do not support D arrangements - Floating-point variants (VFABS, VFNEG, VFSQRT, VFRINT*) only allow floating-point arrangements (S and D) New instructions by group: Integer absolute/negate: VABS, VNEG Floating-point abs/negate: VFABS, VFNEG Floating-point sqrt: VFSQRT Floating-point round: VFRINTN, VFRINTP, VFRINTM, VFRINTZ Saturating abs/negate: VSQABS, VSQNEG Bit/count operations: VCLS, VCLZ, VNOT Change-Id: I62242eda31f82cd34119c7d4f97316a030e7663b Reviewed-on: https://go-review.googlesource.com/c/go/+/762201 Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Keith Randall <khr@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David Chase <drchase@google.com> Auto-Submit: Keith Randall <khr@golang.org>
7 dayscmd/internal/obj/arm64: add ASIMD arithmetic instructionsAlexander Musman
Add encoding support for ASIMD three-register instructions covering floating-point, saturating, halving, integer multiply/accumulate, min/max (including pairwise variants), and bitwise operations. These belong to the "Advanced SIMD Three-register (same)" instruction class defined by the ARM architecture, meaning the two source registers use the same element arrangement (e.g., both .S4 or both .D2). In the assembler they share a common encoding path using the ASIMDSAME() macro. New instructions by group: Floating-point arithmetic: VFADD, VFSUB, VFMUL, VFDIV Floating-point min/max: VFMAX, VFMAXNM, VFMIN, VFMINNM Pairwise floating-point: VFADDP, VFMAXP, VFMINP, VFMAXNMP, VFMINNMP Saturating arithmetic: VSQADD, VUQADD, VSQSUB, VUQSUB Average (halving add): VSHADD, VSRHADD, VUHADD, VURHADD Integer multiply/accum: VMUL, VMLA, VMLS Integer min/max: VSMAX, VSMIN Pairwise integer min/max: VSMAXP, VSMINP, VUMAXP, VUMINP Bitwise: VBIC, VORN Change-Id: I732c84123ad1f302260514fdfe0d020787da017b Reviewed-on: https://go-review.googlesource.com/c/go/+/762200 Auto-Submit: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: David Chase <drchase@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
7 dayscmd/internal/obj/arm64: add ASIMD shift instructionsAlexander Musman
Add support for ASIMD shift instructions. These use the ASIMDSHF encoding class from the ARM architecture specification, where the shift amount is encoded as an immediate derived from the element size. Also add ASIMD shifts-by-vector (3-register form) where the shift amount comes from a second vector register. These use the ASIMDSAME encoding class. New instructions by group: Shift by immediate (signed): VSSHR, VSRSHR Shift by immediate (saturating): VSQSHL, VUQSHL Narrowing shift by immediate: VSHRN, VSHRN2 Shift by vector (3-reg): VSSHL, VUSHL, VSQSHL, VUQSHL Change-Id: I039cc16bc01980b04e6940cc1d4670faf5fa7e3c Reviewed-on: https://go-review.googlesource.com/c/go/+/762180 Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Keith Randall <khr@golang.org> Auto-Submit: Keith Randall <khr@golang.org> Reviewed-by: David Chase <drchase@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
7 dayscmd/internal/obj/arm64: add remaining ASIMD compare instructionsAlexander Musman
Add remaining arm64 ASIMD vector compare instructions. All these instructions produce either all zeroes (false) or all ones (true) bits in each corresponding lane as the result. Added integer comparison instructions: - VCMEQ (compare to zero) - VCMGE, VCMGT (singed, both two-register and compare to zero) - VCMHI, VCMHS (unsigned two-register compare) - VCMLE, VCMLT (signed compare to zero) Added floating-point comparison instructions: - VFCMEQ, VFCMGE, VFCMGT (both two-register and zero variants) - VFCMLE, VFCMLT (compare to zero) Change-Id: I913165d3934f2556c9bdf38c5103ef56d86383ef Reviewed-on: https://go-review.googlesource.com/c/go/+/721640 Auto-Submit: Keith Randall <khr@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com>
7 dayscmd/internal/obj: refactor arm64 ASIMD instruction encodingAlexander Musman
Refactor arm64 ASIMD opcodes to use common helper routines named after their instruction classes from the arm64 XML specification. Add helper routines like ASIMDSAME for instructions with encoding class "asimdsame" in arm64 encodingindex.xml. Helper arguments follow the bitfield order in the speficication tables. For example, the CMEQ instruction entry: <tr class="instructiontable" encname="CMEQ_asimdsame_only"...> <td bitwidth="1" class="bitfield">1</td> <td bitwidth="2" class="bitfield"></td> <td bitwidth="5" class="bitfield">10001</td> <td class="iformname" iformid="CMEQ_advsimd_reg">CMEQ (register)</td> <td class="enctags">Vector</td> </tr> Now corresponds to ASIMDSAME(1, 0, 0x11), where each argument matches the correspoding bitfield value in the table. Change-Id: I024f3eba552906a865841bc1a296f14e3fca73f5 Reviewed-on: https://go-review.googlesource.com/c/go/+/719280 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
11 dayscmd/internal/obj/riscv: add assembly support for Zihintpause extensionsQiu Weihong
Add support for the PAUSE instruction provided by the Zihintpause extension. Change-Id: If06cce4ca57137275f567b5fe29ef85517f381ef Reviewed-on: https://go-review.googlesource.com/c/go/+/710495 Reviewed-by: Joel Sing <joel@sing.id.au> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Junyang Shao <shaojunyang@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
11 dayscmd/internal/obj/loong64: run go generateKeith Randall
"go generate" on this package seems to generate a diff. I have no idea whether this diff is reasonable or not. It looks kinda weird, but maybe? Or perhaps something is wrong with ../mkcnames.go. Change-Id: I3474bab3f6880ffc24c1cf6ec11958a1c9467909 Reviewed-on: https://go-review.googlesource.com/c/go/+/761680 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Keith Randall <khr@golang.org> Reviewed-by: abner chenc <chenguoqi@loongson.cn> Reviewed-by: Meidan Li <limeidan@loongson.cn> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Junyang Shao <shaojunyang@google.com>
14 dayscmd/compile, cmd/link: add linknamestd directive for std-only linknamesCherry Mui
In the standard library, there are a number of linknames, for sharing symbols within the standard library. They are not supposed to be accessed externally. But currently there is no good mechanism to prevent that. In the linker we have a blocklist of linknames, which forbids linkname references other than explicitly allowed packages. The blocklist is manually maintained, requiring periodic manual update. To move away from that manually maintained blocklist, this CL introduces a new directive, linknamestd, that marks a linkname for use within the standard library only. The linker will allow references within the standard library and forbid others. For a proof of concept, runtime.coroswitch is removed from the blocklist, and replaced with linknamestd. An external reference to it is still disallowed by the linker, as tested with cmd/link.TestCheckLinkname with testdata/linkname/coro.go. Change-Id: I0d0f8746b8835d8cdcfc3ff835d22a551da5f038 Reviewed-on: https://go-review.googlesource.com/c/go/+/749942 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David Chase <drchase@google.com>
2026-03-31cmd/internal/obj/riscv: add support for FENCE operands and FENCE.TSOwangboyao
Add support for fine-grained memory ordering flags in the RISC-V FENCE instruction to the assembler. This implements instruction validation and encoding for predecessor and successor flags (I, O, R, W) rather than always falling back to a full memory barrier. This allows more precise memory barriers like FENCE R, RW or FENCE W, W. Additionally, this adds assembly support for the FENCE.TSO, which is encoded as FENCE RW, RW with the fm field set to 1000. Change-Id: Ie9c6c8cd24b38b08013032972bd54515eaedd637 Reviewed-on: https://go-review.googlesource.com/c/go/+/758000 Reviewed-by: Meng Zhuo <mengzhuo1203@gmail.com> Reviewed-by: Junyang Shao <shaojunyang@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Joel Sing <joel@sing.id.au> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2026-03-26cmd/internal/obj/riscv: add assembly support of Zbc extensionXueqi Luo
The Zbc extension adds carry-less multiplication instructions for polynomial arithmetic over GF(2), which is used in cryptographic algorithms and error-correcting codes. The instructions included are: clmul, clmulh, and clmulr. Change-Id: I77a40add1a795c7b90b478dc65835c689e82167a GitHub-Last-Rev: 53790f0aafa46af2ed24183f58292df7f9fb224a GitHub-Pull-Request: golang/go#76301 Reviewed-on: https://go-review.googlesource.com/c/go/+/720520 Reviewed-by: Carlos Amedee <carlos@golang.org> Reviewed-by: Joel Sing <joel@sing.id.au> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2026-03-20cmd/internal/obj/arm64: new arm64 assembling path for SVEJunyang Shao
This CL integrates a new assembling path specifically designed for SVE and other modern ARM64 instructions, utilizing generated instruction tables. It contains the foundational files and modifications to direct the assembling pipeline to use this new data-driven path. In a.out.go, it registers new constants for registers and operand types used by SVE. A new file inst.go is added, which defines the instruction table data types and utility functions for the new path. The entry point from the upstream pipeline is `tryEncode`. `tryEncode` returns false upon an encoding failure, which allows the upstream matching logic to handle multiple potential matches. The exact match is not finalized until an instruction is actually encoded, as detailed in the comments for `elemEncoders`. This CL also introduces the core generated tables (`anames_gen.go`, `encoding_gen.go`, `goops_gen.go`, and `inst_gen.go`) which handle a wide variety of SVE instructions. A comprehensive end-to-end assembly test file (`arm64sveenc.s`) is added, containing hundreds of test cases for these SVE instructions to verify the new encoding path. To facilitate these encodings, this CL implements handling for operand types such as AC_ARNG, AC_PREG, AC_PREGZM, and AC_ZREG. Others are left as TODOs. The generated files in this CL are produced by the `instgen` tool in CL 755180. Original author Eric Fang (eric.fang@arm.com, CL 424137) Change-Id: I483f170c776fcd8edd8b8b04520f9d69ee0855dd Reviewed-on: https://go-review.googlesource.com/c/go/+/742620 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David Chase <drchase@google.com>
2026-03-18cmd/link: modify the register used in trampolinelimeidan
R30 is the callee's saved register; using it requires saving and then restoring. Therefore, we replace it with a register saved by the caller. R4~R19 are argument registers on loong64, and R20 is the only remaining usable caller saved register. To use R20 in trampoline, we modified the registers used by the LoweredMove/LoweredMoveLoop operations (originally using r20 and r21, now changed to R23 and R24). Change-Id: Ie7bba0caa30a764a45bcb47635c35c829036c5a2 Reviewed-on: https://go-review.googlesource.com/c/go/+/726140 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Carlos Amedee <carlos@golang.org> Reviewed-by: abner chenc <chenguoqi@loongson.cn> Reviewed-by: Cherry Mui <cherryyz@google.com>
2026-03-18cmd/link: support loading R_LARCH_GOT64_PC_{LO12, HI20} relocs on loong64Guoqi Chen
On loong64, such relocations are increasingly common when built using an "extreme" code model. To ensure future interoperability with cgo, the linker needs to be made aware of these relocations. Ref: https://github.com/loongson/la-abi-specs/blob/release/laelf.adoc Fixes #78047. Change-Id: Ibca205ab837279c69fb243a8e8519c952e11c99e Reviewed-on: https://go-review.googlesource.com/c/go/+/753521 Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Meidan Li <limeidan@loongson.cn> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Carlos Amedee <carlos@golang.org>
2026-03-17cmd/internal/obj/loong64: centralize the functions for getting instruction ↵limeidan
codes into a single file Change-Id: I174427150f0b099fc8dfc526c1e5b2b40e227c36 Reviewed-on: https://go-review.googlesource.com/c/go/+/753960 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Mark Freeman <markfreeman@google.com> Reviewed-by: Carlos Amedee <carlos@golang.org> Reviewed-by: abner chenc <chenguoqi@loongson.cn>
2026-03-17cmd/internal/obj/loong64: correcting spelling errors in the commentsGuoqi Chen
Change-Id: I8773f3d00a529d11009c4682a191b3b75b15f396 Reviewed-on: https://go-review.googlesource.com/c/go/+/754060 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Carlos Amedee <carlos@golang.org> Reviewed-by: Meidan Li <limeidan@loongson.cn> Reviewed-by: Mark Freeman <markfreeman@google.com>
2026-03-17cmd/compile: don't treat string literal as static data in FIPS modeCherry Mui
Reference a string literal requires a relocation, which is not allowed in static data in FIPS mode, as this would be an absolute relocation, and cannot be properly hashed at both link time and run time. Also, make sure the symbol's FIPS type is set before writing. This ensures relocations are checked in FIPS RODATA symbols. Currently we only call setFIPSType in prewrite if we change the type from a BSS type to a DATA type. But it is possible that the compiler sets the symbol type to RODATA and start writing to it. For #78173. Change-Id: I120a3b28ee3f38e9024479344565f54dff87d430 Reviewed-on: https://go-review.googlesource.com/c/go/+/755600 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Russ Cox <rsc@golang.org>
2026-03-10cmd/compile: fix arm direct tail callKeith Randall
CL 752560 accidentally niled out the target symbol. Re-initialize the target symbol field when doing a direct tail call. Fixes #78053 Change-Id: I007471587a38077b52daa134640d09c7b8b6becb Reviewed-on: https://go-review.googlesource.com/c/go/+/753840 Reviewed-by: Keith Randall <khr@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
2026-03-10cmd/internal/obj/arm: set spadj in arm32 tailcallThea Heinen
In the normal case spadj is not needed because ARET handles the frame pop and return in a single instruction. However, if the ARET is a tailcall then there will be a second instruction where the pcsp stack depth is incorrect. Fixes #78021 Change-Id: I20db57eee03945a369a4b185b8f3311f4accd7ae GitHub-Last-Rev: 7226e2e07472549954ca9771b4f528e208703953 GitHub-Pull-Request: golang/go#78022 Reviewed-on: https://go-review.googlesource.com/c/go/+/752881 Reviewed-by: Mark Freeman <markfreeman@google.com> Reviewed-by: Keith Randall <khr@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@google.com>
2026-03-10cmd/internal/obj/riscv: materialise 32 bit unsigned constantsJoel Sing
Currently, we only materialise 32 bit signed constants - a 32 unsigned value that exceeds the 32 bit signed maximum value is loaded from rodata. A 32 bit unsigned value can be materialized by loading and zero extending, which requires four instructions on rva20u64 - on rva22u64 and above only three instructions are required. Change-Id: I874a457f329ac75c2a0fb59b453cf8ef17df2972 Reviewed-on: https://go-review.googlesource.com/c/go/+/748962 Reviewed-by: Mark Ryan <markdryan@meta.com> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2026-03-10cmd/internal/obj/riscv: factor out constant materialisation codeJoel Sing
Pull the constant materialisation code out into its own function, which reduces indentation and improves readability. Change-Id: Ia06baefa99c8f1a738c1b13d1a8b27111fa948b5 Reviewed-on: https://go-review.googlesource.com/c/go/+/748961 Reviewed-by: David Chase <drchase@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Mark Ryan <markdryan@meta.com> Reviewed-by: Meng Zhuo <mengzhuo1203@gmail.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
2026-03-10cmd/internal/obj/riscv: factor out constant materialisation identificationJoel Sing
Change-Id: Ia7fedd934ecc2b11cb0de445f299dc5c6004e7b0 Reviewed-on: https://go-review.googlesource.com/c/go/+/748960 Reviewed-by: Meng Zhuo <mengzhuo1203@gmail.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Mark Ryan <markdryan@meta.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
2026-03-07cmd/internal/obj: fix indirect tail call codeKeith Randall
The assembler isn't handling this correctly for most architectures. Of course, the two I tried first, arm64 and amd64, worked, so I assumed other archs could handle it also. Apparently not. Should fix dashboard failures introduced by CL 751465. Change-Id: I9fc4f123d11acf3d10cc9806abfb93ec077509a7 Reviewed-on: https://go-review.googlesource.com/c/go/+/752560 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Keith Randall <khr@google.com> Auto-Submit: Keith Randall <khr@golang.org> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2026-03-06cmd/compile: use tail calls for wrappers for embedded interfacesKeith Randall
type I interface { foo() } type S struct { I } Because I is embedded in S, S needs a foo method. We generate a wrapper function to implement (*S).foo. It just loads the embedded field I out of S and calls foo on it. When the thing in S.I itself needs a wrapper, then we have a wrapper calling another wrapper. This can continue, leaving a potentially long sequence of wrappers on the stack. When we then call runtime.Callers or friends, we have to walk an unbounded number of frames to find a bounded number of non-wrapper frames. This really happens, for instance with I = context.Context, S = context.ValueCtx, and runtime.Callers = pprof sample (for any of context.Context's methods). To fix, make the interface call in the wrapper a tail call. That way, the number of wrapper frames on the stack does not increase when there are lots of wrappers happening. Fixes #75764 Fixes #77781 Change-Id: I03b1731159d9218c7f14f72ecbbac822d6a6bb87 Reviewed-on: https://go-review.googlesource.com/c/go/+/751465 Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Cherry Mui <cherryyz@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com>
2026-02-28cmd/internal/obj/loong64: change to get the opcodes of assembly instructions ↵limeidan
from a map Change-Id: I0b481bea96d78d931070a96c392fb329195d17de Reviewed-on: https://go-review.googlesource.com/c/go/+/748380 Reviewed-by: abner chenc <chenguoqi@loongson.cn> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Russ Cox <rsc@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2026-02-27cmd/internal/obj: arm64 assembler support unshifted hi for large offsetsAlexander Musman
Extend splitImm24uScaled to support an unshifted hi value (hi <= 0xfff) in addition to the shifted hi value (hi & ^0xfff000 == 0). This allows load/store instructions to handle more offsets using ADD + load/store sequences instead of falling back to the literal pool. This will be used by a subsequent change to add FMOVQ support in SSA form. Change-Id: I78490f5b1a60d49c1d42ad4daefb5d4e6021c965 Reviewed-on: https://go-review.googlesource.com/c/go/+/737320 Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com> Auto-Submit: Keith Randall <khr@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David Chase <drchase@google.com>
2026-02-27cmd/link, cmd/internal: remove the R_JMPLOONG64 relocation of loong64limeidan
R_JMPLOONG64 and R_CALLLOONG64 have the same functionality, and R_JMPLOONG64 is not used. Change-Id: Id6ac0bfa67025de45f9c51349931142d945134d7 Reviewed-on: https://go-review.googlesource.com/c/go/+/748340 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: David Chase <drchase@google.com> Reviewed-by: abner chenc <chenguoqi@loongson.cn> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
2026-02-24internal/cpu,cmd/internal/obj/arm64: add SBRoland Shoemaker
Add the SB (speculation barrier) instruction, and an internal/cpu feature bit to check its availability. Change-Id: I7c2d887ae75598f7c11cc875ec15ec3be76c09f5 Reviewed-on: https://go-review.googlesource.com/c/go/+/729501 Reviewed-by: David Chase <drchase@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2026-02-23cmd/internal/obj/loong64: remove getting 32-bits address optab entrylimeidan
Change-Id: I082a475179088627d68759e2aaac32472ded2ebe Reviewed-on: https://go-review.googlesource.com/c/go/+/744300 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Mark Freeman <markfreeman@google.com> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: abner chenc <chenguoqi@loongson.cn>
2026-02-23cmd/internal/obj/loong64: merge MOVVF optab entries into ABSFlimeidan
These instructions are aliases for each other: ------------------------------------------------------------------------------- | MOVWF | MOVVF | MOVWD | MOVVD | MOVFW | MOVDW | MOVFV | MOVDV | ------------------------------------------------------------------------------- | FFINTFW | FFINTFV | FFINTDW | FFINTDV | FTINTWF | FTINTWD | FTINTVF | FTINTVD | ------------------------------------------------------------------------------- Change-Id: I435485d5be64a85904609dc8031b4cc88c4746eb Reviewed-on: https://go-review.googlesource.com/c/go/+/741844 Reviewed-by: abner chenc <chenguoqi@loongson.cn> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Mark Freeman <markfreeman@google.com>
2026-02-23cmd/internal/obj/loong64: merge moving data operations into one caselimeidan
Change-Id: I036d4eadeac9210dc03101b27c2375a801b7c2cf Reviewed-on: https://go-review.googlesource.com/c/go/+/741843 Reviewed-by: Mark Freeman <markfreeman@google.com> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: abner chenc <chenguoqi@loongson.cn> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2026-02-23cmd/internal/obj/loong64: merge MOVD optab entries into MOVFlimeidan
Change-Id: Ib6c6bae3f5605a380eff62fd7c2a2537b2661db7 Reviewed-on: https://go-review.googlesource.com/c/go/+/741842 Reviewed-by: abner chenc <chenguoqi@loongson.cn> Reviewed-by: Mark Freeman <markfreeman@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David Chase <drchase@google.com>
2026-02-23cmd/internal/obj/loong64: merge MOVWU optab entries into MOVBUlimeidan
Change-Id: I88cbabe1d2d9448c61fc74207e6a02be96c4d816 Reviewed-on: https://go-review.googlesource.com/c/go/+/741841 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: abner chenc <chenguoqi@loongson.cn> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Mark Freeman <markfreeman@google.com>
2026-02-23cmd/internal/obj/loong64: rearrange optab entrieslimeidan
Change-Id: I32189bb1edf236b8e8f406b2385bdce9071c072a Reviewed-on: https://go-review.googlesource.com/c/go/+/741840 Reviewed-by: abner chenc <chenguoqi@loongson.cn> Reviewed-by: Mark Freeman <markfreeman@google.com> Reviewed-by: Junyang Shao <shaojunyang@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2026-02-22cmd/internal/obj: support arm64 FMOVQ from/to global addressAlexander Musman
Support arm64 FMOVQ from/to global address. Currently there are no global addresses known to be aligned by 16 bytes, and with this CL we will always use R_ADDRARM64 relocation with ADRP+ADD+FMOVQ instructions. Change-Id: I283009eda151d1875cf4457734e79b68a941a6df Reviewed-on: https://go-review.googlesource.com/c/go/+/718001 Auto-Submit: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Keith Randall <khr@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
2026-02-17cmd/internal/obj: remove ARM64 prefix from encoding helpersAlexander Musman
Remove the ARM64 prefix from encoding helper functions that were moved to cmd/internal/obj to be used by both cmd/asm and cmd/compile. These functions now use the package prefix and look like: arm64.EncodeRegisterExtension and arm64.RegisterListOffset. Change-Id: I3548a4fce1072083eb2f55310c9f7ca6a8e12253 Reviewed-on: https://go-review.googlesource.com/c/go/+/714320 Reviewed-by: David Chase <drchase@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
2026-02-17cmd/internal/obj: move ARM64RegisterListOffset from cmd/asm/internal/archAlexander Musman
Change-Id: Ieaacd8c40495e7dad61a068125b1d0e0cee832c4 Reviewed-on: https://go-review.googlesource.com/c/go/+/713500 Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2026-02-14cmd/internal/obj/loong64: improve ARNG type register name conversionGuoqi Chen
When resolving ARNG type names, the base value was not subtracted when calculating the variable simd_type, causing its actual value to not match the expected meaning after the base value adjustment. Fixes #77414 Change-Id: I713bab849ecdb5610d2593ba9bd9e1169842f00e Reviewed-on: https://go-review.googlesource.com/c/go/+/742980 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: WANG Xuerui <git@xen0n.name> Reviewed-by: Michael Pratt <mpratt@google.com> Reviewed-by: Junyang Shao <shaojunyang@google.com> Reviewed-by: Meidan Li <limeidan@loongson.cn>
2026-02-12cmd/compile: set alignment for all content-addressable symbolsIan Lance Taylor
There is nothing particularly special about content-addressable symbols, it's just a place to start. This reduces the size of the tailscaled binary by about 16K. This happens mainly because before this CL the linker's symalign function kicks in for all static composite literals and PCDATA symbols, and gives them an alignment based on their size. If the size happens to be a multiple of 32, it gets an alignment of 32. That wastes space. For #6853 For #36313 Change-Id: I2f049eee8f2463dd2b5e20d7c9a270ac32a31e50 Reviewed-on: https://go-review.googlesource.com/c/go/+/727920 Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Auto-Submit: Ian Lance Taylor <iant@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2026-02-10cmd/internal/obj: add Align field to LSymIan Lance Taylor
This will permit the compiler and assembler to specify the alignment of symbols that they create. Careful placement of the new field, plus rearranging an existing field, means that LSym does not change size (as tested by TestSizeof). The new alignment field is int16, permitting alignment up to 16384, more than we ever need in practice. If necessary we could change the field to uint8 and store the alignment as a power of two, as is done in the linker. This replaces the Align field in FuncInfo. For #6853 For #36313 Change-Id: I421e8238ab57958fea8e4eab0649ce5288e7f92f Reviewed-on: https://go-review.googlesource.com/c/go/+/727020 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@golang.org> Auto-Submit: Ian Lance Taylor <iant@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Keith Randall <khr@google.com>
2026-01-26cmd/compile: reduce lock/scheduler contentionDaniel Morsing
During the parallel section of compilation, we limit the amount of parallelism to prevent scheduler churn. We do this with a worker scheduler, but it does not have insight on when a compilation is blocked due to lock contention. The symbol table was protected with a lock. While most lookups were quick lock->read->unlock affairs, sometimes there would be initialization logic involved. This caused every lookup to stall, waiting for init. Since our worker scheduler couldn't see this, it would not launch new goroutine to "cover" the gap. Fix by splitting the symbol lock into 2 cases, initialization and lookup. If symbols need initialization simultaneously, they will wait for each other, but the common case of looking up a symbol will be handled by a syncmap. In practice, I have yet to see this lock being blocked on. Additionally, get rid of the scheduler goroutine and have each compilation goroutine grab work from a central queue. When multiple compilations finished at the same time, the work scheduler would sometime not get run immediately. This ended up starving the system of work. These 2 changes together cuts -1.37% off the build time of typescriptgo on systems with a lot of cores (specifically, the c3h88 perf builder). Updates #73044. Change-Id: I6d4b3be56fd00a4fdd4df132bcbd52e4b2a3e91f Reviewed-on: https://go-review.googlesource.com/c/go/+/724623 Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@golang.org> Auto-Submit: Keith Randall <khr@golang.org>
generated by cgit v1.3 (git 2.53.0) at 2026-04-15 07:33:57 +0000