flambda optimizations depends on unrelated things

[vicuna]

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

• fragile.ml

[vicuna]

Comment author: Alex

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

[vicuna]

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]

Comment author: @xclerc

Pull request: #1313

[vicuna]

Comment author: @lpw25

The PR was merged so marking as resolved.