-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
noinline attribute for functions #640
Labels
Milestone
Comments
As with other annotations,
|
andrewrk
added
the
proposal
This issue suggests modifications. If it also has the "accepted" label then it is planned.
label
Dec 3, 2017
andrewrk
added a commit
that referenced
this issue
Dec 6, 2017
* add @noInlineCall - see #640 This fixes a crash in --release-safe and --release-fast modes where the optimizer inlines everything into _start and clobbers the command line argument data. If we were able to verify that the user's code never reads command line args, we could leave off this "no inline" attribute. * add i29 and u29 primitive types. u29 is the type of alignment, so it makes sense to be a primitive. probably in the future we'll make any `i` or `u` followed by digits into a primitive. * add `aligned` functions to Allocator interface * add `os.argsAlloc` and `os.argsFree` so that you can get a `[]const []u8`, do whatever arg parsing you want, and then free it. For now this uses the other API under the hood, but it could be reimplemented to do a single allocation. * add tests to make sure command line argument parsing works.
andrewrk
changed the title
Proposal: no-inline and @noInlineCall
noinline attribute for functions
Nov 21, 2018
It is already possible to specify What is still missing is the counterpart for the |
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
C/C++ has nonstandard constructs like
__noinline
or__attribute__((noinline))
. When coding I am much more certain when I do not wish something to inline, than the opposite. Reducing code bloat is easier to think about than guessing performance impact.I propose for Zig:
no-inline
, opposite toinline
. Calling@inlineCall
on it would be compile error.@noInlineCall
, opposite to@inlineCall
. Calling@noInlineCall
oninline
function would be compile error.Possibly, syntax for
@inlineCall
and@noInlineCall
could be:The text was updated successfully, but these errors were encountered: