From: Ethan Burns <burns.ethan@gmail.com>
To: caml-list@inria.fr
Subject: [Caml-list] Comparing variant types
Date: Thu, 28 Apr 2011 15:16:16 -0400 [thread overview]
Message-ID: <BANLkTi=55g=rwiRm03_eS=uyGGDCoi4ezg@mail.gmail.com> (raw)
Hi,
I have a program that uses variant types as an enumeration. While
profiling, I noticed that compare_val was being called a bunch. When
I went to inspect why this was the case, it turns out that it was
being called to compare equality of my variants. I am a bit confused,
however, because my understanding was that variants that are declared
without an 'of' clause were just represented as integers and therefore
a type containing only these simple elements should be directly
comparable (no compare_val).
While looking further into this, I found a little example where the
compiler seems to produce a simple comparison in one case and not in
another:
type dir = Left | Right | Up | Down | No_op
(* performs a simple comparison *)
let f a = a <> Right
(* calls out to C to do compare_val *)
let g (a:dir) b = a <> b
There is the -dlambda output:
(seq
(let (f/69 (function a/70 (!= a/70 1a)))
(setfield_imm 0 (global Test!) f/69))
(let (g/71 (function a/72 b/73 (caml_notequal a/72 b/73)))
(setfield_imm 1 (global Test!) g/71))
0a)
Since both functions know that the types of the elements being compare
is 'dir', which contains only simple elements, why does the g function
still use compare_val? Does the compiler not perform this particular
optimization?
Best,
Ethan
next reply other threads:[~2011-04-28 19:16 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-28 19:16 Ethan Burns [this message]
2011-04-28 21:07 ` Vincent Aravantinos
2011-04-28 22:56 ` Ethan Burns
[not found] ` <354087020.772283.1304031467793.JavaMail.root@zmbs4.inria.fr>
2011-04-29 8:46 ` Fabrice Le Fessant
2011-04-29 8:57 ` Dmitry Bely
[not found] ` <164004794.892685.1304067487325.JavaMail.root@zmbs2.inria.fr>
2011-04-29 9:33 ` luc.maranget
2011-04-29 10:54 ` Andrew
2011-04-29 11:17 ` Dmitry Bely
2011-04-29 12:15 ` Jon Harrop
2011-04-30 16:38 ` Andrew
2011-04-29 11:32 ` Dmitry Bely
2011-04-30 13:43 ` craff73
2011-04-30 19:26 ` Andrew
2011-04-30 20:19 ` Gabriel Scherer
2011-04-30 20:57 ` Yaron Minsky
[not found] <fa.FGXk5PCsQgS8TidmFkgljpqbLZo@ifi.uio.no>
2011-04-29 11:54 ` Ethan Burns
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='BANLkTi=55g=rwiRm03_eS=uyGGDCoi4ezg@mail.gmail.com' \
--to=burns.ethan@gmail.com \
--cc=caml-list@inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox