From: Xavier Leroy <Xavier.Leroy@inria.fr>
To: Jean-Christophe.Filliatre@ens-lyon.fr
Cc: caml-list@inria.fr
Subject: Re: compilation
Date: Tue, 18 Feb 1997 17:53:08 +0100 (MET) [thread overview]
Message-ID: <199702181653.RAA29053@pauillac.inria.fr> (raw)
In-Reply-To: <199702131524.QAA03489@anjou.ens-lyon.fr> from Jean-Christophe Filliatre at "Feb 13, 97 04:24:19 pm"
> [english summary at the end of this mail]
> 1. J'aimerai savoir si :
>
> let b = true
> let f = if b then f1 else f2
>
> est compilé en f1, c'est-à-dire si la branche d'un "if" est
> directement sélectionnée lorsque le booléen est "true" ou "false"
> (sans l'évaluer, bien sûr ; simplement directement égal à "true" ou
> "false" au moment de la compilation)
Non, il n'y a pas de propagation des constantes dans le compilateur
Objective Caml. Cependant, b n'est teste qu'une seule fois, et non pas
a chaque appel de f, qui se branche directement sur le code de f1
(voir question suivante).
> La raison de ma question est que cela permettrait d'avoir des options
> de compilation directement en Caml sans perdre d'efficacité.
C'est possible, a condition de bien sortir les tests des
fonctions. P.ex. ne pas ecrire
let f x if debug then ...;
...
(test a chaque appel de f), mais plutot
let f if debug then fun x -> ...; ...
else fun x -> ...
> 2. de la même manière, est-ce que
>
> let f = fun x -> e
> let f1 = f
>
> est compilé en remplaçant tout appel à f1 par un appel à f ?
Oui. En fait, les identificateurs f et f1 ont la meme valeur
fonctionnelle, qui est une fermeture du code de fun x -> e.
> Ma question est, là encore, de savoir si on ne perd pas
> d'efficacité en renommant des fonctions.
Il n'y a pas de surcout a l'appel de fonction.
- Xavier Leroy
> =english====================================================================>
> 1. I would like to know if
>
> let b = true
> let f = if b then f1 else f2
>
> is compiled as f1, that is if the branch of an "if" expression is
> directly selected when the boolean expression is "true" or "false"
> (without performing any computation on it, of course; just directly
> equal to the constructor "true" or "false").
No, there's no constant folding in the compiler. However, b will be
tested only once, not at each call to f, so that's still fairly efficient.
> 2. the same way, is
>
> let f = fun x -> e
> let f1 = f
>
> compiled by replacing any call to f1 by a call to f ?
No, f and f1 have the same functional value: a closure of the code for
fun x -> e.
> The question is still to known if we don't loose efficiency by
> renaming functions.
We don't.
next prev parent reply other threads:[~1997-02-18 17:38 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
1997-02-13 15:24 compilation Jean-Christophe Filliatre
1997-02-18 15:26 ` compilation David Monniaux
1997-02-18 16:53 ` Xavier Leroy [this message]
1997-02-19 8:12 compilation Franck Cassez
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=199702181653.RAA29053@pauillac.inria.fr \
--to=xavier.leroy@inria.fr \
--cc=Jean-Christophe.Filliatre@ens-lyon.fr \
--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