Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/compile: duplicate blocks calling runtime.panicXXX in some procedures #24478

Closed
laboger opened this issue Mar 21, 2018 · 3 comments

Comments

Projects
None yet
4 participants
@laboger
Copy link
Contributor

commented Mar 21, 2018

Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?

tip

Does this issue reproduce with the latest release?

yes

What operating system and processor architecture are you using (go env)?

Tried ppc64le and x86

What did you do?

While looking at some objdumps I noticed some functions that had several blocks of code at the end of the procedure with calls to runtime.panicXXX functions. In some cases there were many duplicate blocks calling the same function.

What did you expect to see?

The blocks containing identical calls could be collapsed into a single block, with all predecessors branching to the same block.

What did you see instead?

Here is an example on ppc64le from function runtime.selectgo. Similar code appears in the x86 objdump.

    100402a0:   81 b9 fe 4b     bl      1002bc20 <runtime.panicindex>
    100402a4:   00 00 00 00     .long 0x0
    100402a8:   79 b9 fe 4b     bl      1002bc20 <runtime.panicindex>
    100402ac:   00 00 00 00     .long 0x0
    100402b0:   71 b9 fe 4b     bl      1002bc20 <runtime.panicindex>
    100402b4:   00 00 00 00     .long 0x0
    100402b8:   69 b9 fe 4b     bl      1002bc20 <runtime.panicindex>
    100402bc:   00 00 00 00     .long 0x0
    100402c0:   61 b9 fe 4b     bl      1002bc20 <runtime.panicindex>
    100402c4:   00 00 00 00     .long 0x0
    100402c8:   59 b9 fe 4b     bl      1002bc20 <runtime.panicindex>
    100402cc:   00 00 00 00     .long 0x0
    100402d0:   51 b9 fe 4b     bl      1002bc20 <runtime.panicindex>
    100402d4:   00 00 00 00     .long 0x0
    100402d8:   49 b9 fe 4b     bl      1002bc20 <runtime.panicindex>
    100402dc:   00 00 00 00     .long 0x0
    100402e0:   41 b9 fe 4b     bl      1002bc20 <runtime.panicindex>
    100402e4:   00 00 00 00     .long 0x0
    100402e8:   39 b9 fe 4b     bl      1002bc20 <runtime.panicindex>
    100402ec:   00 00 00 00     .long 0x0
    100402f0:   31 b9 fe 4b     bl      1002bc20 <runtime.panicindex>
    100402f4:   00 00 00 00     .long 0x0
    100402f8:   29 b9 fe 4b     bl      1002bc20 <runtime.panicindex>
    100402fc:   00 00 00 00     .long 0x0
    10040300:   21 b9 fe 4b     bl      1002bc20 <runtime.panicindex>
    10040304:   00 00 00 00     .long 0x0
    10040308:   19 b9 fe 4b     bl      1002bc20 <runtime.panicindex>
    1004030c:   00 00 00 00     .long 0x0
    10040310:   11 b9 fe 4b     bl      1002bc20 <runtime.panicindex>
    10040314:   00 00 00 00     .long 0x0

Fixing this would reduce the size of the function, possibly enabling more inlining, and reduce the size of the binary.

@randall77

This comment has been minimized.

Copy link
Contributor

commented Mar 21, 2018

There are multiple calls because each corresponds to a different source line. We wouldn't get accurate line numbers in tracebacks if we coalesced all the panicindex calls in a function.

We do combine multiple identical panics from the same line. For instance, a[i] + b[j] should only generate a single panicindex call.

@andybons

This comment has been minimized.

Copy link
Member

commented Mar 21, 2018

@randall77 what is the next step, here? Are you saying this should be closed or is more investigation needed?

@andybons andybons added this to the Unplanned milestone Mar 21, 2018

@randall77

This comment has been minimized.

Copy link
Contributor

commented Mar 21, 2018

I guess we should close this unless someone comes up with a better way to encode line numbers during panic.

@randall77 randall77 closed this Mar 21, 2018

@golang golang locked and limited conversation to collaborators Mar 21, 2019

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.