[go-nuts] What's the basic block layout algorithm ?

[eric...@arm.com]

Hi,
I was looking at the layout pass recently, but I didn't find any documents 
about it. I would like to ask what algorithm is used for this pass? There 
is not much code for this pass, but if there is some documentation, it will 
be more convenient to understand it.

The layout pass has something to do with register allocation. I know that 
register allocation uses linear scan algorithm. If anyone could tell me a 
document, presentation or blog describing its implementation, I would be 
very grateful.

Thanks
Eric

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/b2de09d4-c32d-49ea-ab13-2b1b789b187bn%40googlegroups.com.

[go-nuts] Re: What's the basic block layout algorithm ?

[eric...@arm.com]

Thanks Keith, then I will just read the code directly. Fortunately, the 
code does not seem to be a lot. I think branch is a bit too much in some 
cases, such as the math.IsInf function, so I want to see if I can optimize 
it somewhere.

在2020年7月22日星期三 UTC+8 上午9:05:46 写道：

> It's not a fancy algorithm. It tries to layout blocks connected by 
> high-likelihood edges together. It also tries to keep panic paths at the 
> end.
> I don't know of any documentation for it, other than the code.
>
> There's nothing particularly important in the layout pass to help with 
> register allocation. It helps a linear-scan allocator to have blocks 
> connected by high-likelihood edges be adjacent. But that layout is 
> independently useful to avoid branch instructions, and non-linear-scan 
> allocators probably like that layout also.
>
> On Tuesday, July 21, 2020 at 4:05:26 AM UTC-7 eric...@arm.com wrote:
>
>> Hi,
>> I was looking at the layout pass recently, but I didn't find any 
>> documents about it. I would like to ask what algorithm is used for this 
>> pass? There is not much code for this pass, but if there is some 
>> documentation, it will be more convenient to understand it.
>>
>> The layout pass has something to do with register allocation. I know that 
>> register allocation uses linear scan algorithm. If anyone could tell me a 
>> document, presentation or blog describing its implementation, I would be 
>> very grateful.
>>
>> Thanks
>> Eric
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/6007a70f-d383-4c1f-8689-d5e6f389ce0en%40googlegroups.com.

[go-nuts] Register spilling size

[eric...@arm.com]

Hi,

Can someone tell me why does OpStoreReg of type int16, int32, etc. occupy 8 
bytes on the stack? And where is this handled ? Thanks.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/60e89c13-7625-4ab8-8d5b-5add8e21378cn%40googlegroups.com.

[go-nuts] Re: Register spilling size

[eric...@arm.com]

Hi Keith, thank you for your response. Sorry I didn't say that I saw this 
issue on linux/arm64. For your example above, the result on linux/arm64 is 
like this:
go tool compile -S tmp.go 
 
0x001c 00028 (spill.go:4)   MOVD"".p(FP), R0
0x0020 00032 (spill.go:4)   MOVH(R0), R1
0x0024 00036 (spill.go:4)   MOVHR1, "".x-8(SP)
0x0028 00040 (spill.go:5)   MOVD"".q+8(FP), R2
0x002c 00044 (spill.go:5)   MOVH(R2), R3
0x0030 00048 (spill.go:5)   MOVHR3, "".y-16(SP)
0x0034 00052 (spill.go:6)   PCDATA  $1, ZR
0x0034 00052 (spill.go:6)   CALL"".g(SB)
0x0038 00056 (spill.go:7)   MOVH"".y-16(SP), R0
0x003c 00060 (spill.go:7)   MOVD"".p(FP), R1
0x0040 00064 (spill.go:7)   MOVHR0, (R1)
0x0044 00068 (spill.go:8)   MOVH"".x-8(SP), R0
0x0048 00072 (spill.go:8)   MOVD"".q+8(FP), R1
0x004c 00076 (spill.go:8)   MOVHR0, (R1)

Obviously it is 8 bytes.
在2020年11月4日星期三 UTC+8 上午6:39:30 写道：

> It don't think it does. For instance, an int16 will be spilled to a 2-byte 
> slot in the stack frame.
> Can you show us what you are seeing? This is what I tried:
>
> package main
>
> func f(p, q *int16) {
> x := *p
> y := *q
> g()
> *p = y
> *q = x
> }
> func g()
>
> go tool compile -S tmp.go
>
> 0x001d 00029 (tmp1.go:4) MOVQ "".p+24(SP), AX
> 0x0022 00034 (tmp1.go:4) MOVWLZX (AX), CX
> 0x0025 00037 (tmp1.go:4) MOVW CX, "".x+6(SP)
> 0x002a 00042 (tmp1.go:5) MOVQ "".q+32(SP), DX
> 0x002f 00047 (tmp1.go:5) MOVWLZX (DX), BX
> 0x0032 00050 (tmp1.go:5) MOVW BX, "".y+4(SP)
> 0x0037 00055 (tmp1.go:6) CALL "".g(SB)
> 0x003c 00060 (tmp1.go:7) MOVWLZX "".y+4(SP), AX
> 0x0041 00065 (tmp1.go:7) MOVQ "".p+24(SP), CX
> 0x0046 00070 (tmp1.go:7) MOVW AX, (CX)
> 0x0049 00073 (tmp1.go:8) MOVWLZX "".x+6(SP), AX
> 0x004e 00078 (tmp1.go:8) MOVQ "".q+32(SP), CX
> 0x0053 00083 (tmp1.go:8) MOVW AX, (CX)
>
>
> On Monday, November 2, 2020 at 3:29:49 AM UTC-8 eric...@arm.com wrote:
>
>> Hi,
>>
>> Can someone tell me why does OpStoreReg of type int16, int32, etc. occupy 
>> 8 bytes on the stack? And where is this handled ? Thanks.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/98541019-d750-4968-8ba1-29cc18085889n%40googlegroups.com.

[go-nuts] Re: Register spilling size

[eric...@arm.com]

I got it, the code is 
here 
https://github.com/golang/go/blob/633f9e206045176a12c301eb2c249c1c1d9a5d2e/src/cmd/compile/internal/gc/pgen.go#L186,
 
I don't know why the slot is required to be aligned at least 8 bytes on 
these architectures. I will try to see if this requirement can be removed 
on linux/arm64, 
and to determine the slot size based on the actual size of the variable, 
just like linux/amd64 does.

在2020年11月4日星期三 UTC+8 上午9:38:12 写道：

> Hi Keith, thank you for your response. Sorry I didn't say that I saw this 
> issue on linux/arm64. For your example above, the result on linux/arm64 is 
> like this:
> go tool compile -S tmp.go 
>  
> 0x001c 00028 (spill.go:4)   MOVD"".p(FP), R0
> 0x0020 00032 (spill.go:4)   MOVH(R0), R1
> 0x0024 00036 (spill.go:4)   MOVHR1, "".x-8(SP)
> 0x0028 00040 (spill.go:5)   MOVD"".q+8(FP), R2
> 0x002c 00044 (spill.go:5)   MOVH(R2), R3
> 0x0030 00048 (spill.go:5)   MOVHR3, "".y-16(SP)
> 0x0034 00052 (spill.go:6)   PCDATA  $1, ZR
> 0x0034 00052 (spill.go:6)   CALL"".g(SB)
> 0x0038 00056 (spill.go:7)   MOVH"".y-16(SP), R0
> 0x003c 00060 (spill.go:7)   MOVD"".p(FP), R1
> 0x0040 00064 (spill.go:7)   MOVHR0, (R1)
> 0x0044 00068 (spill.go:8)   MOVH"".x-8(SP), R0
> 0x0048 00072 (spill.go:8)   MOVD"".q+8(FP), R1
> 0x004c 00076 (spill.go:8)   MOVHR0, (R1)
>
> Obviously it is 8 bytes.
> 在2020年11月4日星期三 UTC+8 上午6:39:30 写道：
>
>> It don't think it does. For instance, an int16 will be spilled to a 
>> 2-byte slot in the stack frame.
>> Can you show us what you are seeing? This is what I tried:
>>
>> package main
>>
>> func f(p, q *int16) {
>> x := *p
>> y := *q
>> g()
>> *p = y
>> *q = x
>> }
>> func g()
>>
>> go tool compile -S tmp.go
>>
>> 0x001d 00029 (tmp1.go:4) MOVQ "".p+24(SP), AX
>> 0x0022 00034 (tmp1.go:4) MOVWLZX (AX), CX
>> 0x0025 00037 (tmp1.go:4) MOVW CX, "".x+6(SP)
>> 0x002a 00042 (tmp1.go:5) MOVQ "".q+32(SP), DX
>> 0x002f 00047 (tmp1.go:5) MOVWLZX (DX), BX
>> 0x0032 00050 (tmp1.go:5) MOVW BX, "".y+4(SP)
>> 0x0037 00055 (tmp1.go:6) CALL "".g(SB)
>> 0x003c 00060 (tmp1.go:7) MOVWLZX "".y+4(SP), AX
>> 0x0041 00065 (tmp1.go:7) MOVQ "".p+24(SP), CX
>> 0x0046 00070 (tmp1.go:7) MOVW AX, (CX)
>> 0x0049 00073 (tmp1.go:8) MOVWLZX "".x+6(SP), AX
>> 0x004e 00078 (tmp1.go:8) MOVQ "".q+32(SP), CX
>> 0x0053 00083 (tmp1.go:8) MOVW AX, (CX)
>>
>>
>> On Monday, November 2, 2020 at 3:29:49 AM UTC-8 eric...@arm.com wrote:
>>
>>> Hi,
>>>
>>> Can someone tell me why does OpStoreReg of type int16, int32, etc. 
>>> occupy 8 bytes on the stack? And where is this handled ? Thanks.
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/ebdd0219-ea29-4449-8c6e-e42066da7dedn%40googlegroups.com.

Re: [go-nuts] Re: Register spilling size

[eric...@arm.com]

Yes, as Keith said, the 16-byte alignment requirement of sp is for the size 
of the entire stack, and there is no such requirement for a single variable 
on the stack. We can access a single variable through sp+/-offset.
The code has already dealt with the overall alignment of sp. I tried to 
remove the alignment requirement for a single variable on linux/arm64, and 
all the tests in all.bash passed. So I think this alignment requirement for 
a single variable is unnecessary on linux/arm64. In addition, I also 
checked the result generated by gcc. In the case of -O0, the alignment of a 
single variable on the stack is consistent with its own size.

在2020年11月5日星期四 UTC+8 上午8:21:34 写道：

> Ah, arm64.
> That code jesper points to looks like the culprit.
> The whole stack frame alignment should be handled separately from the 
> alignment of individual variables, so the total alignment needed shouldn't 
> matter.
>
> Not sure why we do that. A small archaeology dive indicates this code 
> dates from when the compiler was written in C. No indication of why it was 
> added.
> I've opened an issue to look at this. 
> https://github.com/golang/go/issues/42386
> On Wednesday, November 4, 2020 at 5:51:03 AM UTC-8 jesper.lou...@gmail.com 
> wrote:
>
>> On Wed, Nov 4, 2020 at 9:36 AM eric...@arm.com  wrote:
>>
>>> I got it, the code is here 
>>> https://github.com/golang/go/blob/633f9e206045176a12c301eb2c249c1c1d9a5d2e/src/cmd/compile/internal/gc/pgen.go#L186
>>> , 
>>> I don't know why the slot is required to be aligned at least 8 bytes on 
>>> these architectures. I will try to see if this requirement can be removed 
>>> on linux/arm64, 
>>> and to determine the slot size based on the actual size of the variable, 
>>> just like linux/amd64 does.
>>>
>>>
>> If my memory serves (and it is spotty, you should definitely look it up) 
>> arm64 requires sp to be 16-byte aligned (or two times the word size to be 
>> precise), and this is a hardware requirement if accessing memory.
>>
>> There might be other reasons to want aligned access pertaining to 
>> atomicity guarantees and memory models. If the garbage collector assumes 
>> certain things about memory access when it is doing its unspeakable things 
>> to the stack, you may want it to have alignment to ensure certain 
>> operations behave nicely. Tread carefully, my friend.
>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/6a52dee6-bf89-4365-ad95-96af119fc261n%40googlegroups.com.

[go-nuts] Failed to install golang.org/x/tools

[eric...@arm.com]

Os: ubuntu 18.04
Arch: arm64 linux
go version: go1.15.7
What did I do:
 $ go get -u golang.org/x/tools/...
package mvdan.cc/gofumpt/format: unrecognized import path 
"mvdan.cc/gofumpt/format": reading 
https://mvdan.cc/gofumpt/format?go-get=1: 404 Not Found
But with the tip version of Go, I can download and install x/tools 
successfully. Am I missing any configurations ?

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/548152bb-5d21-452e-8703-d69cef8ac287n%40googlegroups.com.

Re: [go-nuts] How to verify whether gollvm is picked

[eric...@arm.com]

I don't know why you can't see 'gccgo' or 'gollvm', on my machine,
For main Go,
$ go version
go version go1.16.2 linux/arm64
For gccgo,
$ go version
go version go1.14.2 gccgo (GCC) 11.0.0 20200603 (experimental) linux/arm64
For gollvm,
$ go version
go version go1.16.5 gollvm LLVM 13.0.0git linux/amd64

在2021年6月28日星期一 UTC+8 下午5:51:41 写道：

> Thank you. In `go version` command I cannot see `gccgo` or `gollvm`
>
> But in `go build -x` command has mentioned that, `llvm-goc` is running 
> located at `/usr/local/bin`.
>
> On Monday, 28 June 2021 at 02:53:53 UTC+5:30 Ian Lance Taylor wrote:
>
>> On Sat, Jun 26, 2021 at 11:59 PM Kavindu Gimhan Zoysa
>>  wrote:
>> >
>> > I have ran the commands in 
>> https://go.googlesource.com/gollvm/#installing, (I did not run `ninja 
>> install-gollvm`). Then I set the path of bin folder to my $PATH using 
>> `export PATH=build-debug/bin:$PATH`.
>> >
>> > Finally, I was able to run `go build/run test.go` successfully.
>> >
>> > But my problem is since I have already installed golang to my machine 
>> before install gollvm, how do I verify that go build command picked gollvm, 
>> instead of golang's compiler?
>>
>> Run "go version" and look for "gccgo" or "gollvm" in the output.
>>
>> Or, run "go build -x" to see exactly what commands it is running.
>>
>> Ian
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/2ba5ff1b-68fb-4032-9d9f-b4656649fc24n%40googlegroups.com.

[go-nuts] Re: Writing SIMD ASM

[eric...@arm.com]

> I see there's an existing issue to add a bunch of Neon floating point 
instructions:
> https://github.com/golang/go/issues/41092
>
> I actually spent a while having a go at adding the instructions myself, 
but couldn't figure it out.
>
> I also see that there is also a proposal and a MR to refactor the Arm64 
assembler.
> https://github.com/golang/go/issues/44734
>
> Is there any ongoing work there, or has that effort stalled?

I'm working on these issues. The plan is refactoring the assembler first, 
the newly designed assembler should make it easier to add instructions. As 
you said, there are a large number of arm64 instructions (NEON, SVE) that 
are not supported and we want to spend as little effort as possible on this.

But this will take some time, although the code is already under review. If 
you want to use some of the instructions as soon as possible, please submit 
an issue, or use word to workaround it first.  Thanks~
在2022年1月21日星期五 UTC+8 10:15:26 写道：

> Hi team,
>
> I'm a recent Gopher, and have had great success over the past year 
> developing an insurance modelling application. The tooling is great, thanks 
> to the team for creating it.
>
> 1) SIMD Workflow
>
> I've got hot functions in my application which are doing element wise 
> operations on float slices. Some are just element-wise addition, and 
> multiplication, some are slightly more complicated.
>
> I'm currently deploying on AWS Lambda X86 which as AX2 support (Xeon 
> Haswell+), but I'm also experimenting with Arm64 (Graviton 2), and would 
> also like to do some benchmarking on Graviton 3 (only available on EC2 ATM).
>
> I've been experimenting with implementing the hot functions in Go's ASM 
> dialect, and using some simple code generation, to handle all the 
> repetition. Nothing fancy, not much more than string templating. The 
> results have been pretty good, but the workflow is pretty slow.
>
> As a side project I've been toying with the idea of writing a slightly 
> more advanced tool, that could read a "SIMD kernel" written as a simple Go 
> function with a specific form, and generate ASM implementations for it. No 
> fancy optimisations, just loop unrolling and vector instructions.
>
> For example:
>
> import . asmgen
>
> // Implementation in a generated .s file
> func Foo(dst []float32, a float32, x, y []float32)
>
> // AST used as input to ASM codegen
> func kernelFoo(i int, dst []float32, a float32, x, y []float32) {
> dst[i] = min(a * x[i], y[i])
> }
>
> In reality, I probably don't have the time to do that, but it does feel 
> like something minimal that would actually cover most of my immediate use 
> cases is not a huge amount of work.
>
> I guess this is basically just a limited form of c2goasm . See: 
> https://github.com/minio/c2goasm
>
> So maybe I should just use that, however including big blobs of hex 
> encoded ASM doesn't seem great either. See: 
> https://github.com/apache/arrow/blob/master/go/parquet/internal/utils/min_max_neon_arm64.s
>
> So apologies that this question is a bit vague and rambly. But the 
> workflow for SIMD here is pretty slow, and it feels like there could be a 
> better way to solve this. So I'm basically just reaching out to see if 
> anyone else has been working on this, or thinking about it, or has ideas 
> about better solutions.
>
>
> 2) Arm64 ASM Neon Instructions:
>
> One problem that's come up, is there's a bunch of ARM instructions which 
> aren't defined in Go's assembler. So it looks like I'm going to have to 
> write some code to generate the hex for these. I can probably copy the 
> approach used here: 
> https://github.com/minio/asm2plan9s/blob/master/asm2plan9s_arm64.go
>
> For example - I'm currently writing:
>
> WORD $0x4E24D400 // fadd v0.4s, v0.4s, v4.4s
>
> But would like write:
>
> VFADD V0.S4, V0.S4, V4.S4
>
> I see there's an existing issue to add a bunch of Neon floating point 
> instructions:
> https://github.com/golang/go/issues/41092
>
> I actually spent a while having a go at adding the instructions myself, 
> but couldn't figure it out.
>
> I also see that there is also a proposal and a MR to refactor the Arm64 
> assembler.
> https://github.com/golang/go/issues/44734
>
> Is there any ongoing work there, or has that effort stalled?
>
> Anyways, thanks for reading my big wall of text.
>
> Cheers,
> Greg.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/21c896c5-c6a4-4d18-8268-ea045b91e008n%40googlegroups.com.

[go-nuts] Re: gollvm compilation issue

[eric...@arm.com]

I just filed a patch for this issue, 
see https://go-review.googlesource.com/c/gollvm/+/384394

在2022年2月9日星期三 UTC+8 14:57:08 写道：

> I tried to build gollvm with the latest llvm, but it failed with several 
> compilation errors, such as the one below. Using llvm-13.0.0 resulted in 
> compilation errors too. Did anyone get into similar errors?
>
> /home/user/code/llvm/llvm-project/llvm/tools/gollvm/passes/GoStatepoints.cpp: 
> In function ‘llvm::AttributeList legalizeCallAttributes(llvm::LLVMContext&, 
> llvm::AttributeList)’:
> /home/user/code/llvm/llvm-project/llvm/tools/gollvm/passes/GoStatepoints.cpp:1286:38:
>  
> error: conversion from ‘llvm::AttributeSet’ to non-scalar type 
> ‘llvm::AttrBuilder’ requested
>  1286 |   AttrBuilder FnAttrs = AL.getFnAttrs();
> /home/user/code/llvm/llvm-project/llvm/tools/gollvm/passes/GoStatepoints.cpp:1292:22:
>  
> error: cannot convert ‘llvm::Attribute’ to ‘const llvm::AttributeMask&’
>  1292 |   FnAttrs.remove(A);
>   |  ^
>   |  |
>   |  llvm::Attribute
> In file included from 
> /home/user/code/llvm/llvm-project/llvm/include/llvm/IR/Argument.h:18,
>  from 
> /home/user/code/llvm/llvm-project/llvm/include/llvm/IR/Function.h:25,
>  from 
> /home/user/code/llvm/llvm-project/llvm/include/llvm/IR/PassManager.h:45,
>  from 
> /home/user/code/llvm/llvm-project/llvm/tools/gollvm/passes/GoStatepoints.h:20,
>  from 
> /home/user/code/llvm/llvm-project/llvm/tools/gollvm/passes/GoStatepoints.cpp:15:
> /home/user/code/llvm/llvm-project/llvm/include/llvm/IR/Attributes.h:1041:44: 
> note:   initializing argument 1 of ‘llvm::AttrBuilder& 
> llvm::AttrBuilder::remove(const llvm::AttributeMask&)’
>  1041 |   AttrBuilder &remove(const AttributeMask &AM);
>   |   ~^~
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/e8fe8444-f303-426c-992a-f347e5b106a1n%40googlegroups.com.

Re: [go-nuts] Why doesn't Go use atomic.LoadInt32() in sync.Mutex.lockSlow()?

[eric...@arm.com]

Why is it not safe to read here? The real write operation is done through 
CAS, assuming the read value is out of date, then the CAS operation will 
fail.

在2022年4月2日星期六 UTC+8 11:41:00 写道：

> On Fri, Apr 1, 2022 at 8:31 PM 机智的小小帅  wrote:
> >
> > Hi,all. I'm reading the source code of sync package recently.
> >
> > Here is a code snippet in sync/mutex.go.
> >
> > // src/sync/mutex.go
> > type Mutex struct {
> > state int32
> > sema uint32
> > }
> >
> > func (m *Mutex) lockSlow() {
> > var waitStartTime int64
> > starving := false
> > awoke := false
> > iter := 0
> > old := m.state // Here!!! not use atomic.LoadInt32()
> > for {
> > // Don't spin in starvation mode, ownership is handed off to waiters
> > // so we won't be able to acquire the mutex anyway.
> > if old&(mutexLocked|mutexStarving) == mutexLocked && 
> runtime_canSpin(iter) {
> > // Active spinning makes sense.
> > // Try to set mutexWoken flag to inform Unlock
> > // to not wake other blocked goroutines.
> > if !awoke && old&mutexWoken == 0 && old>>mutexWaiterShift != 0 &&
> > atomic.CompareAndSwapInt32(&m.state, old, old|mutexWoken) {
> > awoke = true
> > }
> > // ...
> > old = m.state // And here!!! not use atomic.LoadInt32()
> > continue
> > }
> > // ...
> > }
> > // ...
> > }
> >
> >
> > You can see full context in link1 and link2
> >
> > I have read The Go Memory Model, It says "Reads and writes of values 
> larger than a single machine word behave as multiple machine-word-sized 
> operations in an unspecified order."
> >
> > Althought it is usually 32 or 64 bits on modern machine,I think if you 
> want a operator is atomic,you should use atomic.LoadXXX() explicitly.
> >
> > I think a ordinary read operator like old := m.state in concurrent 
> environment is not safe,it may read a unexpected value.
> >
> > I wonder whether the oridinary read operation is right? Could you help 
> me? Thanks in advance.
> >
> > I'm very sorry to disturb you...
>
> When reading or writing a value that is the size of a memory word or
> smaller and is aligned such that the value does not cross a word
> boundary in memory Go assumes that the entire value will always be
> read or written as a unit. This is true of all processors that Go
> currently supports.
>
> The purpose of an atomic operation is different: it is about when the
> value is visible to other cores on the same system.
>
> Ian
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/fe33644e-45c3-43ac-8d60-1053fb40a6bdn%40googlegroups.com.

[go-nuts] noinline is 25% faster than inline on apple m1 ?

[eric...@arm.com]

For this piece of code, two test functions are the same, but one is 
inlined, the other is not. However the inlined version is about 25% slower 
than the no inlined version on apple m1 chip. Why is it?

The code is here https://go.dev/play/p/0NkLMtTZtv4

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/527264d7-7cc1-4278-9a29-c04eb3ec4e86n%40googlegroups.com.

[go-nuts] What's the maximum array length?

[eric...@arm.com]

The spec says that " The length is part of the array's type; it must 
evaluate to a non-negative constant  
representable  by a value of 
type int. ", so on a 64-bit environment, I assume that the maximum array 
length should be math.MaxInt64, am I right ? But the following code doesn't 
compile:

package main
var x = [1<<34]byte{1<<23: 23, 1<<24: 24, 1<<33:33}

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/e295dd1c-2abd-4709-a6c4-1252ef635b5en%40googlegroups.com.

Re: [go-nuts] Re: What's the maximum array length?

[eric...@arm.com]

> That appears to be the primary limit. That including a composite literal 
initializer that exceeds that limit, causing a more ambiguous error, > 
seems like a related, but secondary, issue.

Yes, this seems to be a related question, see 
https://github.com/golang/go/issues/9862. If we do not allow static data 
larger than 2G, then the description of the array in the spec may need to 
be slightly modified?

在2022年10月29日星期六 UTC+8 17:37:32 写道：

> On Saturday, October 29, 2022 at 3:52:16 PM UTC+8 
> axel.wa...@googlemail.com wrote:
>
>> You might want to check out the order of messages as seen by google 
>> groups: https://groups.google.com/g/golang-nuts/c/mw5f2kyEjpA
>> Either your Message was delivered to groups delayed, or Kurtis message 
>> was delivered delayed to you.
>>
>
> I don't think the order matters at all here. ;)
>  
>
>>
>> On Sat, Oct 29, 2022 at 9:44 AM T L  wrote:
>>
>>>
>>>
>>> On Sat, Oct 29, 2022 at 12:11 PM Kurtis Rader  
>>> wrote:
>>>
>>> Did you not see my reply pointing out the same thing? That is, given a 
>>> particular platform and executable format the limit is likely to be much 
>>> less than math.MaxInt. Alternatively, was my reply not clear about the 
>>> practical versus theoretical limit of the size of an array? Which is not to 
>>> say that your reply is invalid. I'm just curious how you view your reply as 
>>> being more clear than mine. :-)
>>>
>>>
>>>> On Fri, Oct 28, 2022 at 8:57 PM tapi...@gmail.com  
>>>> wrote:
>>>>
>>>>> The max array length is math.MaxInt. "[math.MaxInt]struct{}" is valid,
>>>>> though the practical size of non-zero-size array is hard limited in 
>>>>> some way.
>>>>>
>>>>> On Friday, October 28, 2022 at 9:43:16 AM UTC+8 eric...@arm.com wrote:
>>>>>
>>>>>> The spec says that " The length is part of the array's type; it must 
>>>>>> evaluate to a non-negative constant 
>>>>>> <https://go.dev/ref/spec#Constants> representable 
>>>>>> <https://go.dev/ref/spec#Representability> by a value of 
>>>>>> type int. ", so on a 64-bit environment, I assume that the maximum array 
>>>>>> length should be math.MaxInt64, am I right ? But the following code 
>>>>>> doesn't 
>>>>>> compile:
>>>>>>
>>>>>> package main
>>>>>> var x = [1<<34]byte{1<<23: 23, 1<<24: 24, 1<<33:33}
>>>>>>
>>>>> -- 
>>>>> You received this message because you are subscribed to the Google 
>>>>> Groups "golang-nuts" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send 
>>>>> an email to golang-nuts...@googlegroups.com.
>>>>> To view this discussion on the web visit 
>>>>> https://groups.google.com/d/msgid/golang-nuts/df18462d-4ec1-4287-ad71-ef4aa0d85a5dn%40googlegroups.com
>>>>>  
>>>>> <https://groups.google.com/d/msgid/golang-nuts/df18462d-4ec1-4287-ad71-ef4aa0d85a5dn%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>> .
>>>>>
>>>>
>>>>
>>>> -- 
>>>> Kurtis Rader
>>>> Caretaker of the exceptional canines Junior and Hank
>>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to golang-nuts...@googlegroups.com.
>>>
>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/golang-nuts/CAHbs%3DNbmgsUet1GW4AbbBeOQ9xeUZd92ybb28L-m1O8-Ze3CtQ%40mail.gmail.com
>>>  
>>> <https://groups.google.com/d/msgid/golang-nuts/CAHbs%3DNbmgsUet1GW4AbbBeOQ9xeUZd92ybb28L-m1O8-Ze3CtQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/624b7b28-b750-40a0-9407-d3fe16d1f956n%40googlegroups.com.