[m-dev.] diff: don't inline throw/1 and rethrow/1
Fergus Henderson
fjh at cs.mu.OZ.AU
Thu Mar 9 22:48:30 AEDT 2000
I was reading some generated C code the other day,
and I noticed that the compiler was inlining throw/1,
so that it expanded into a call to type_to_univ
followed by a call to builtin_throw/1. That seemed
like a bad idea, hence the following change.
An alternative would be to change the inlining heuristic
so that it didn't inline anything whose determinism
was `erroneous', but there are some cases where doing
that can be a slight win, and anyway the following
was easier to implement.
----------
Estimated hours taken: 0.25
library/exception.m:
Add `pragma no_inline' directives to ensure that
throw/1 and rethrow/1 are not inlined. Doing so
increases the code size without any useful increase
in speed.
Workspace: /d-drive/home/hg/fjh/mercury
Index: library/exception.m
===================================================================
RCS file: /home/mercury1/repository/mercury/library/exception.m,v
retrieving revision 1.10.2.2
diff -u -d -r1.10.2.2 exception.m
--- library/exception.m 2000/02/25 17:48:52 1.10.2.2
+++ library/exception.m 2000/03/08 14:35:40
@@ -273,6 +273,13 @@
"Det = ML_CC_MULTI"
).
+% These are not worth inlining, since they will
+% (presumably) not be called frequently, and so
+% any increase in speed from inlining is not worth
+% the increase in code size.
+:- pragma no_inline(throw/1).
+:- pragma no_inline(rethrow/1).
+
throw(Exception) :-
type_to_univ(Exception, Univ),
builtin_throw(Univ).
--
Fergus Henderson <fjh at cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3 | -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to: mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions: mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------
More information about the developers
mailing list