Re: [PATCH] Move profiling to SSA

[Geert Bosch <bosch at adacore dot com>]

On Sep 23, 2010, at 18:24, Jan Hubicka wrote:

> this patch adds leaf attribute broken up and updated
> http://gcc.gnu.org/ml/gcc-patches/2010-06/msg01329.html
> 
> + @item leaf
> + @cindex @code{leaf} function attribute
> + Calls to external functions with this attribute must return to the current
> + compilation unit only by return or by exception handling. In particular, leaf
> + functions are not allowed to call callback function passed to it from current
> + compilation unit or directly call functions exported by the unit or longjmp
> + into the unit.  Still leaf function might call functions from other complation
> + units and thus they are not neccesarily leaf in the sense that they contains no
> + function calls at all.
Wouldn't it be better to call this "nocallback"? The term 
leaf functions is already taken in this context, and indeed
means something different.

If I understand correctly, indirect function calls within a library function
marked "leaf" would still be OK. What about the function holding on to
addressed of data passed by reference? I guess that would not be OK, as
it seems you really want to assure calling the function causes no pointers
to escape.
> + 
> + The attribute is intended for library functions to improve dataflow analysis.
> + Compiler takes the hint that any data not escaping current compilation unit can
> + not be used or modified by the leaf function.  For example, function @code{sin}
> + is leaf, function @code{qsort} is not.
> + 
> + Note that the leaf functions might invoke signals and signal handlers might be
> + defined in the current compilation unit and use static variables. Only
> + compliant way to write such a signal handler is to declare such variables
> + @code{volatile}.
What you are implementing seems somewhat similar to Ada accessibility levels.
Essentially, the idea is that you can't pass local pointers to more global
functions in a way that they escape. For example, it would be fine for a
global function to modify global variables, or to pass a pointer to a
global function. However, it is not allowed to pass a pointer to local
storage in a global variable or to pass a pointer to a local function to
a global function. In this context C's static variables are just a kind
of global variable, as their lifetime is the same.

In a way, the attribute you propose seems more like a "noescape" attribute,
or describing functions as "closed". So, it is still OK to have a signal handler,
as long as no pointers to local info escape to global variables.
About longjmp, what about systems using setjmp/longjmp for exception handling?
That seems just an implementation detail to me, and this use does not
violate any of the constraints to avoid escape of pointers.

> + 
> + The attribute has no effect on functions defined within current compilation
> + unit.  This is to allow easy merging of multiple compilation units into one,
> + for example, by using the link time optimization.  For this reason the
> + attribute is not allowed on types to annotate indirect calls.

I'm not quite sure what you mean here. The issues about avoiding escape of
local data is not really so much about indirect function calls, as about
the lifetime (or accessibility level) associated with a pointer, and
with variables.

Could you elaborate a bit more on the precise model you are trying to implement?
Also, I think the current attribute name "leaf" is a bit unfortunate. Maybe
if we can nail down its semantics a better name becomes clear.

Regards,
  -Geert

  -Geert