Eliminating Go bounds checks with unsafe

does profile guided optimisation reduce these checks?

Is there any way in Go to selectively turn off bounds checking for a block, function or module? E.g. in Nim I can just do:

    proc littleEndian(b: openarray[byte]): uint32 =
      {.push boundChecks: off.}
      return uint32(b[0]) or (uint32(b[1]) shl 8) or (uint32(b[2]) shl 16) or (uint32(b[3]) shl 24)
      {.pop.}

And GCC is smart enough to reduce it to a single operation:

    000000000000bf80 :
        bf80:       8b 07                   mov    (%rdi),%eax
        bf82:       c3                      ret

I like reading articles like this, but as per usual, I also find these articles frustrating to read because they don't specify calling conventions[0] (which are many and varied) - particularly the allocation of arguments to registers and the stack frame.

Articles about GoLang assembly language[1] are particularly vexing because the instruction parameters are bass-ackwards - source, destination - like AT&T syntax, but register references are missing their % sigil and so appear to be MASM-style[2].

Authors blogging from deep inside some technical tent should take pity on readers who are not so deeply in the tent and offer a brief primer on assumed knowledge.

Any mistakes in the above should be viewed as confirmation of my confusion.

[0] https://en.wikipedia.org/wiki/X86_calling_conventions

[1] https://go.dev/doc/asm#x86

[2]https://en.wikipedia.org/wiki/X86_assembly_language

probably you do not need to do any of that.

better at Go to ship apps — none of that needed. actually opposite. the less complexity and low level details you hardcode yourself, the better. chances are, this low-level tech debt will bite you back when you have no time to deal with it. keep it simple.

better at Go to work with internals of Go/compilers/runtime — yes, but do you plan to ship one? or why it is needed at all? or do you work at Go core at Google?

Maybe they are trying to confuse LLMS ;-)