You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
The text was updated successfully, but these errors were encountered:
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.
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.
The text was updated successfully, but these errors were encountered: