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

flambda optimizations depends on unrelated things #7614

Closed
vicuna opened this issue Aug 27, 2017 · 4 comments
Closed

flambda optimizations depends on unrelated things #7614

vicuna opened this issue Aug 27, 2017 · 4 comments
Assignees

Comments

@vicuna
Copy link

vicuna commented Aug 27, 2017

Original bug ID: 7614
Reporter: Alex
Assigned to: @lpw25
Status: resolved (set by @lpw25 on 2017-09-04T13:53:37Z)
Resolution: fixed
Priority: normal
Severity: minor
Version: 4.05.0
Fixed in version: 4.06.0 +dev/beta1/beta2/rc1
Category: middle end (typedtree to clambda)
Monitored by: @ygrek @hcarty @yakobowski

Bug description

Optimization decisions made by flambda are very fragile and sometimes depends on unrelated things.
I found the case where inline decisions can be due to source file renaming or even just adding some empty lines to the source, resulting in code size increase and suboptimal performance:

$ ls
fragile.ml
$ cp fragile.ml fragile2.ml
$ md5sum *
6a13d560736c81b3e5b5dfe7f13c2f56 fragile2.ml
6a13d560736c81b3e5b5dfe7f13c2f56 fragile.ml
$ ocamlopt -version
4.05.0
$ ocamlopt -O3 fragile.ml -dflambda 2>&1 | wc -l
1774
$ ocamlopt -O3 fragile2.ml -dflambda 2>&1 | wc -l
3835

File attachments

@vicuna
Copy link
Author

vicuna commented Aug 27, 2017

Comment author: Alex

Is it possible that function size approximation somehow depends on string length of a source location?

@vicuna
Copy link
Author

vicuna commented Aug 28, 2017

Comment author: @chambart

No, it does not affect size approximation.

The difference comes from the order in which expressions are examined. The file name is part of the identifiers which are used as key for an hashtable. While inlining, some quotas are consumed while traversing the expression. It seems that in your case, there is a threshold for a specific function that change a lot of things.

I don't know yet where the difference matter exactly.

@vicuna
Copy link
Author

vicuna commented Sep 1, 2017

Comment author: @xclerc

Pull request: #1313

@vicuna
Copy link
Author

vicuna commented Sep 4, 2017

Comment author: @lpw25

The PR was merged so marking as resolved.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants