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

proposal: cmd/compile: no bound check compiler directive #47529

Closed
jfcg opened this issue Aug 4, 2021 · 11 comments
Closed

proposal: cmd/compile: no bound check compiler directive #47529

jfcg opened this issue Aug 4, 2021 · 11 comments
Labels
Projects
Milestone

Comments

@jfcg
Copy link

@jfcg jfcg commented Aug 4, 2021

Hi,
I am proposing the following directive to disable bound checking (what -B compiler option does) per function (including closures), like:

//go:noboundcheck
func someFunc() int {
  ..
}

func otherFunc(x int) int {
  ..
  //go:noboundcheck
  cl := func() {
    // do something with x
  }
  ..
}
  • The directive will greatly help carefully written, low level, performance critical functions like a lesswap closure where the compiler has no way to prove/disprove bounds safety.
  • There would be many other regular functions and closures where it would be very useful.
  • It is much safer to use this directive at certain places than to use -B on a package or an entire project.
  • It will affect only the function following the directive (and not any closures inside that function, unless they are also tagged).
@gopherbot gopherbot added this to the Proposal milestone Aug 4, 2021
@robpike
Copy link
Contributor

@robpike robpike commented Aug 4, 2021

I would very much prefer this not happen, as it breaks memory safety with no recourse. Decades of history with C have taught us that even skilled programmers enable overflows inadvertently, with dire consequences. What it does in the hands of less skilled programmers, or even skilled ones who import one inadvertently, is not to be countenanced.

Go has bound checks for a reason: Humans are not good enough at guaranteeing indexes stay in bounds. Putting one's hand up and saying, "yes I am" is insufficient.

Loading

@mvdan
Copy link
Member

@mvdan mvdan commented Aug 4, 2021

If a human can prove a bounds check is unnecessary within a scope or func body, I would hope we can teach the compiler to do the same. That has been improving over the past half decade.

Loading

@jfcg
Copy link
Author

@jfcg jfcg commented Aug 4, 2021

I agree with you all but in the lesswap case for example, the closure and the sorting library (user of the closure) live in different packages. They may even be compiled at different times and places. There is nothing to teach the compiler. There is just no way it can guess lesswap should not have bound checks. Using the closure with the right/wrong indices is the library's responsibility/fault.

Loading

@mvdan
Copy link
Member

@mvdan mvdan commented Aug 4, 2021

If performance trumps safety for your library, perhaps consider using unsafe? Forcing the compiler to disable memory safety is practically the same, but worse since the user would not be aware that unsafe is involved.

Loading

@josharian
Copy link
Contributor

@josharian josharian commented Aug 4, 2021

Related: #30582

Loading

@ianlancetaylor ianlancetaylor added this to Incoming in Proposals Aug 4, 2021
@ianlancetaylor ianlancetaylor changed the title proposal: no bound check compiler directive proposal: cmd/compile: no bound check compiler directive Aug 4, 2021
@rsc rsc moved this from Incoming to Active in Proposals Aug 4, 2021
@rsc
Copy link
Contributor

@rsc rsc commented Aug 4, 2021

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

Loading

@beoran
Copy link

@beoran beoran commented Aug 4, 2021

Why is there even a -B flag? I'd rather propose to remove that as well in stead.

Loading

@bcmills
Copy link
Member

@bcmills bcmills commented Aug 4, 2021

in the lesswap case for example, the closure and the sorting library (user of the closure) live in different packages. They may even be compiled at different times and places. There is nothing to teach the compiler.

The compiler emits export data for packages, and — at least for unexported functions and function literals — it can, in theory, reason about those functions based on what they are passed to. In addition, even an exported function may be inlined or specialized at particular call sites, and techniques like profile-guided optimization may allow that to be done even in a language like Go that aims to keep build times and binary sizes low.

So, at least in theory, the export data for the sorty package could include information about the ranges of values it will pass to the Lesswap function, and the compiler could eliminate the bounds checks there.

(Here I'm really just expounding on @mvdan's more fundamental observation in #47529 (comment). Facts that are obvious to human maintainers should also be “obvious enough” to automated tools.)

Loading

@zephyrtronium
Copy link
Contributor

@zephyrtronium zephyrtronium commented Aug 5, 2021

@beoran

Why is there even a -B flag? I'd rather propose to remove that as well in stead.

The -B flag helps to quantify the cost of bounds checks in a program, which allows developers to decide when it is worthwhile to optimize them out.

Loading

@rsc
Copy link
Contributor

@rsc rsc commented Aug 11, 2021

Based on the discussion above, this proposal seems like a likely decline.
— rsc for the proposal review group

Loading

@rsc rsc moved this from Active to Likely Decline in Proposals Aug 11, 2021
@rsc rsc moved this from Likely Decline to Declined in Proposals Aug 18, 2021
@rsc
Copy link
Contributor

@rsc rsc commented Aug 18, 2021

No change in consensus, so declined.
— rsc for the proposal review group

Loading

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Proposals
Declined
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
9 participants