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

inlining does not reduce polymorphism to concrete type to generate optimized code #5592

Closed
vicuna opened this issue Apr 16, 2012 · 1 comment

Comments

@vicuna
Copy link

vicuna commented Apr 16, 2012

Original bug ID: 5592
Reporter: goswin
Status: resolved (set by @gasche on 2012-04-17T18:20:39Z)
Resolution: suspended
Priority: normal
Severity: minor
Version: 3.12.1
Category: back end (clambda to assembly)
Duplicate of: #5541
Related to: #7440
Monitored by: ronan.lehy@gmail.com goswin @hcarty

Bug description

Consider these three functions:

let f1 x y = x = y
let f2 (x:int) y = x = y
let f3 (x:int) y = f1 x y

val f1 : 'a -> 'a -> bool =
val f2 : int -> int -> bool =
val f3 : int -> int -> bool =

One would think that f2 and f3 would generate the same code:

0000000000403550 <camlBaz__f1_1030>:
403550: 48 83 ec 08 sub $0x8,%rsp
403554: 48 89 c7 mov %rax,%rdi
403557: 48 89 de mov %rbx,%rsi
40355a: 48 8b 05 7f 75 21 00 mov 0x21757f(%rip),%rax # 61aa
e0 <_DYNAMIC+0x638>
403561: e8 a6 e2 00 00 callq 41180c <caml_c_call>
403566: 48 83 c4 08 add $0x8,%rsp
40356a: c3 retq
40356b: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)

0000000000403570 <camlBaz__f2_1033>:
403570: 48 39 d8 cmp %rbx,%rax
403573: 0f 94 c0 sete %al
403576: 48 0f b6 c0 movzbq %al,%rax
40357a: 48 8d 44 00 01 lea 0x1(%rax,%rax,1),%rax
40357f: c3 retq

0000000000403580 <camlBaz__f3_1036>:
403580: 48 83 ec 08 sub $0x8,%rsp
403584: 48 89 c7 mov %rax,%rdi
403587: 48 89 de mov %rbx,%rsi
40358a: 48 8b 05 4f 75 21 00 mov 0x21754f(%rip),%rax # 61aae0 <_DYNAMIC+0x638>
403591: e8 76 e2 00 00 callq 41180c <caml_c_call>
403596: 48 83 c4 08 add $0x8,%rsp
40359a: c3 retq
40359b: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)

But as you can see in f3 the generic polymorphic code from f1 is inlined resulting in a caml_c_call instead of reducing the polymorphism to int and generating the same optimized code as in f2.

@vicuna
Copy link
Author

vicuna commented Apr 17, 2012

Comment author: @gasche

This is actually the same issues as #5541 (but your title is more informative). I'll add a link between the two and replicate the resolution status. Quoting here xleroy's answer:

Unfortunately, type-based specialization of comparisons takes place
before inlining. In other words, even if min & max were inlined,
they would still use the generic comparison operator. That's one of
the several weaknesses of the OCaml inliner. I'm not expecting
a solution soon, which is why I'm putting this PR in "suspended" state.

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

1 participant