Skip to content

Duplicate main and __original_main #12787

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

Open
juj opened this issue Nov 15, 2020 · 4 comments
Open

Duplicate main and __original_main #12787

juj opened this issue Nov 15, 2020 · 4 comments
Labels

Comments

@juj
Copy link
Collaborator

juj commented Nov 15, 2020

It looks like if one builds with a main that is of form int main(){...}, there will be this kind of stub

 (func $main (; 3 ;) (param $0 i32) (param $1 i32) (result i32)
  (call $__original_main)
 )
 (func $__original_main (; 5 ;) (result i32)
    ...

that will be generated, but not inlined away even in -O3. Is that something that would be possible to optimize away?

@sbc100
Copy link
Collaborator

sbc100 commented Nov 15, 2020

We do have special handling for that case in binaryen. There is a pass called
InlineMainPass (one the command line: "inline-main") which does just this.

Maybe this stopping being run at some point... we should investigate.

However, I somewhat surprised that this pass is even needed? Should binaryen
be able to always inline in cases like this? i.e. can't we make a general pass that basically say:

"If a function has just a single caller, and the function is not exported, inline the function into its caller.. no matter how big the function is?" Is there any situation where that is not desirable? Or we could be more specific and add "if the calling function is trivial.. i.e. its a wrapper"

@sbc100
Copy link
Collaborator

sbc100 commented Nov 15, 2020

Ah, yes it looks like this was removed in #11995. I guess the normal inlining passes at -O3 not removing this, contrary to what the comment that PR says?

@sbc100
Copy link
Collaborator

sbc100 commented Nov 15, 2020

From my brief experiments it looks like this is getting correctly inlined at -O2 and above.. but adding -g seems to prevent the inlining.

This seems wrong. -g is not supposed to effect code generation of optimization at all.

@stale
Copy link

stale bot commented Apr 17, 2022

This issue has been automatically marked as stale because there has been no activity in the past year. It will be closed automatically if no further activity occurs in the next 30 days. Feel free to re-open at any time if this issue is still relevant.

@stale stale bot added the wontfix label Apr 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants