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: 6670 Reporter: mxu Status: closed (set by @alainfrisch on 2014-11-24T16:45:28Z) Resolution: duplicate Priority: normal Severity: tweak Version: 4.02.1 Category: back end (clambda to assembly) Duplicate of:#4800 Monitored by:@Drup@gasche
Bug description
Background: Sometimes it is convenient to refer to fields of records using alternative names. For example, if a published formula uses certain variable names, it can improve readability and reduce the chance of errors to use the variables names given in the publication.
Suppose that some curious operation on two fractions were stated: "Given a/b and c/d, z = ad+bc."
Given the type, which is a reasonable definition for a fraction,
type t = { num: int; denom: int }
a function for z could be written as
let f1 r1 r2 = r1.num * r2.denom + r1.denom * r2.num
and with such a simple expression it is a minor issue to make the translation in names. For complicated computations, it becomes more of an issue.
I would like to right something straightforward like
let f2 r1 r2 = let (a, b, c, d) = (r1.num, r1.denom, r2.num, r2.denom) in
ad + bc
However, f2 produces substantially larger code than f1, apparently because it constructs a tuple explicitly. I can't tell whether something this is just an optimization that has not been made or if something in the OCaml language requires that the tuple be constructed. If the increased readability did not impose a large code size penalty.
Strangely, refactoring the code to use a pattern match
let f3 r1 r2 =
match (r1.num, r1.denom, r2.num, r2.denom) with
| (a, b, c, d) -> ad + bc
resulted in instructions very similar to f1, but with some changes in order.
Finally, a suggestion from #ocaml below results in code identical to the original, although the function parameters are less readable (to me):
let f4 { num = a ; denom = b } { num = c ; denom = d } = a*d + b*c
Steps to reproduce
Run ocamlopt -S test.ml
View test.s file
Additional information
I'm attaching compilable source (test.ml), along with the full test.s produced. In addition, I have extracted the assembly code for each function and placed the results in test-asm. To facilitate comparison, I have arranged them in the order f1 and f4 (identical), f3 (similar but different sequence), and f2 (longest).
Original bug ID: 6670
Reporter: mxu
Status: closed (set by @alainfrisch on 2014-11-24T16:45:28Z)
Resolution: duplicate
Priority: normal
Severity: tweak
Version: 4.02.1
Category: back end (clambda to assembly)
Duplicate of: #4800
Monitored by: @Drup @gasche
Bug description
Background: Sometimes it is convenient to refer to fields of records using alternative names. For example, if a published formula uses certain variable names, it can improve readability and reduce the chance of errors to use the variables names given in the publication.
Suppose that some curious operation on two fractions were stated: "Given a/b and c/d, z = ad+bc."
Given the type, which is a reasonable definition for a fraction,
type t = { num: int; denom: int }
a function for z could be written as
let f1 r1 r2 = r1.num * r2.denom + r1.denom * r2.num
and with such a simple expression it is a minor issue to make the translation in names. For complicated computations, it becomes more of an issue.
I would like to right something straightforward like
let f2 r1 r2 = let (a, b, c, d) = (r1.num, r1.denom, r2.num, r2.denom) in
ad + bc
However, f2 produces substantially larger code than f1, apparently because it constructs a tuple explicitly. I can't tell whether something this is just an optimization that has not been made or if something in the OCaml language requires that the tuple be constructed. If the increased readability did not impose a large code size penalty.
Strangely, refactoring the code to use a pattern match
let f3 r1 r2 =
match (r1.num, r1.denom, r2.num, r2.denom) with
| (a, b, c, d) -> ad + bc
resulted in instructions very similar to f1, but with some changes in order.
Finally, a suggestion from #ocaml below results in code identical to the original, although the function parameters are less readable (to me):
Steps to reproduce
Run ocamlopt -S test.ml
View test.s file
Additional information
I'm attaching compilable source (test.ml), along with the full test.s produced. In addition, I have extracted the assembly code for each function and placed the results in test-asm. To facilitate comparison, I have arranged them in the order f1 and f4 (identical), f3 (similar but different sequence), and f2 (longest).
File attachments
The text was updated successfully, but these errors were encountered: