On Sat, Nov 5, 2022 at 4:57 AM Chris Burkert <burkert.ch...@gmail.com> wrote:
> I am curious: from a compiler perspective, does that mean that by using _ > simply less assembler instructions are created by not handling those > registers which relate to _? > > That kind of depends on what you mean by "not handling". Since it's a compile-time error (in the GC compiler) to have an unused variable, you'd have to do something else with that value. Depending on what type that ignored return value is, whether the call is inlined and whether the call is using the newer, register-based calling convention the compiler *may* be able to prune instructions related to that variable. Here are a few scenarios off the top of my head (in no particular order and by no means exhaustive, but some of them are interesting -- and some are completely hypothetical optimizations as I haven't looked at a lot of the relevant compiler code myself): - The call doesn't get inlined, and it's a trivial value that can be passed around in a register, so that return register is simply never read (and gets clobbered at some later point when it's needed) - The call is inlined, and the variable that it's returned from doesn't interact with anything in the callee, so the code for generating that return variable can be removed during a dead-code removal pass - The call is inlined and that return value is a pointer to something on the heap, in which case the stack pointer-liveness map for that point in the function will mark that pointer as dead (I'm not certain about this one) -- this might let the heap object get GC'd from that moment. - The call is assembly so it's eligible for neither the newer register-calling convention nor inlining, so the spot on the stack for that return value just gets ignored until the function returns (or that stack-space gets allocated to another variable) - cgo can't return multiple values, but if you ignore the return value in AMD64 calling conventions it's a register that can be ignored. (although it may be a pointer to something elsewhere in memory, in which case gets more interesting) - The call is inlined and the return value is a pointer which would normally be marked as escaping but because the pointer gets ignored, the compiler can go back to stack-allocating. (I'm not sure if the compiler has a second escape-analysis pass like this, but it could be interesting) Marcel Huijkman <marcel.huijk...@semrush.com> schrieb am Sa. 5. Nov. 2022 > um 09:18: > >> When I explain it during my training I always say it is a trashcan >> variable, anything you put in is to be ignored on the spot. >> >> On Friday, November 4, 2022 at 10:10:20 PM UTC+1 Konstantin Khomoutov >> wrote: >> >>> On Fri, Nov 04, 2022 at 04:58:35AM -0700, Canuto wrote: >>> >>> > I'm just starting out with go ... >>> > I have searched for lights on this string but without success. >>> > What does this sign mean " _, err " , what the underscore symbol means >>> here? >>> >>> If you're starting with Go, please start with the Go Tour [1]. >>> For instance, the use of this underscore sign is covered in [2]. >>> >>> 1. https://go.dev/tour/ >>> 2. https://go.dev/tour/moretypes/17 >>> >>> -- >> 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/6c745c54-b212-4bb6-8e40-00273e6ee2fan%40googlegroups.com >> <https://groups.google.com/d/msgid/golang-nuts/6c745c54-b212-4bb6-8e40-00273e6ee2fan%40googlegroups.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/CALWqRZo-n%3D_16Ug8Rids3E502dFZcW5PPZueGKfDqA%2Bcg30X6A%40mail.gmail.com > <https://groups.google.com/d/msgid/golang-nuts/CALWqRZo-n%3D_16Ug8Rids3E502dFZcW5PPZueGKfDqA%2Bcg30X6A%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/CANrC0BjkRus%2B-kV5Wdq7vwiLinqiuRyX7o5LbtXnDh_BHqD%2BxQ%40mail.gmail.com.
