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

noinline attribute for functions #640

Closed
PavelVozenilek opened this issue Dec 2, 2017 · 3 comments
Closed

noinline attribute for functions #640

PavelVozenilek opened this issue Dec 2, 2017 · 3 comments
Labels
accepted This proposal is planned. proposal This issue suggests modifications. If it also has the "accepted" label then it is planned.
Milestone

Comments

@PavelVozenilek
Copy link

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:

  • function annotation no-inline, opposite to inline. Calling @inlineCall on it would be compile error.
  • builtin @noInlineCall, opposite to @inlineCall. Calling @noInlineCall on inline function would be compile error.

Possibly, syntax for @inlineCall and @noInlineCall could be:

fn foo() -> i32 {...}
...
var x = inline foo();
var y = no-inline foo();

@PavelVozenilek
Copy link
Author

As with other annotations, inline/no-inline may be dependent on environment:

fn foo(comptime b : bool) 
{
  if (b) {
inline:
    return;
  }

no-inline:
   // long computation here which is better not to be inlined
   ...
}

@andrewrk andrewrk added this to the 0.3.0 milestone Dec 3, 2017
@andrewrk 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 andrewrk modified the milestones: 0.3.0, 0.4.0 Feb 28, 2018
@andrewrk andrewrk changed the title Proposal: no-inline and @noInlineCall noinline attribute for functions Nov 21, 2018
@andrewrk andrewrk added the accepted This proposal is planned. label Nov 21, 2018
@andrewrk andrewrk modified the milestones: 0.4.0, 0.5.0 Mar 14, 2019
@andrewrk andrewrk modified the milestones: 0.5.0, 0.6.0 Aug 28, 2019
@andrewrk andrewrk modified the milestones: 0.6.0, 0.7.0 Dec 9, 2019
@andrewrk andrewrk modified the milestones: 0.7.0, 0.8.0 Oct 9, 2020
@andrewrk andrewrk modified the milestones: 0.8.0, 0.9.0 May 19, 2021
@andrewrk andrewrk modified the milestones: 0.9.0, 0.10.0 Nov 20, 2021
@andrewrk andrewrk modified the milestones: 0.10.0, 0.11.0 Apr 16, 2022
@cztomsik
Copy link

cztomsik commented Dec 12, 2022

It is already possible to specify .modifier = .never_inline for the @call

What is still missing is the counterpart for the inline fn.
Maybe what about something like inline(.always) and inline(.never)?
Or we can just close this as wontfix?

@Vexu
Copy link
Member

Vexu commented Dec 12, 2022

noinline has existed for a long time #3178, not sure why this was left open.

@Vexu Vexu closed this as completed Dec 12, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
accepted This proposal is planned. proposal This issue suggests modifications. If it also has the "accepted" label then it is planned.
Projects
None yet
Development

No branches or pull requests

4 participants