Re: simple calls.c cleanups (help on trees needed)

[Jan Hubicka <hubicka at atrey dot karlin dot mff dot cuni dot cz>]

> On Thu, Mar 30, 2000 at 01:48:30PM +0200, Jan Hubicka wrote:
> > While implementing it I found that we don't support nothrow and malloc
> > attributes at the fuction types.  Is that some kind of design decision
> > or just omision?
> 
> I thought we did support nothrow on types.  Oh, though it's 
> in the C++ part of the tree.  Oh well, the CALL_EXPR also has
> nothrow marked.

I will look at the C++ bits and make C frontend to accept that attribute too.
It looks like it is not hard, since nothrow is in the common section.

> 
> Dunno about the malloc attribute.
OK
I will try to commonize way the attributes are handled.  It looks like every
new attribute is added with slightly different semantic.
I near future I would like to re-try to add the attribute "pure", so at least
I would learn how to do that cleanly.
The const and noreturn flags does use VOLATILE and CONST fields of nodes, that
seems to be OK.  Interestingly nothrow uses ((NODE)->common.nothrow_flag),
but malloc uses (NODE)->decl.malloc_flag. So I believe I can't use malloc
attribute in the type.

Mark: Can you show me to the right dirrection? It looks to me that correct
way is to add those to the common section. I've checked and three flags
are free. After adding "malloc" and "pure" attributes, only one can be left.

Is there some more curefull was to add those to the types? Perhaps use
two flags ->decl.malloc_flag and ->type.malloc_flag to not waste the common
section.  Then the accessor macro can choose the right one.

Or is there some more sensible scheme?
> 
> I bet this whole function would get much cleaner if we 
> used gprof to recognize the functions.  Not a requirement
> for this patch, but a suggestion for future cleanup.
OK. In the near future I would like to slowly move towards to merging
emit_library_call_value_1 and expand_call (at least the internal loop)
and make it handling sibcall then.

Once this is done I can take a look at this, OK?
> 
> > !       if (flags & (ECF_CONST || ECF_MALLOC))
> 
>  "|"
OOps!
> 
> Otherwise ok.
Thanks.

Honza
> 
> 
> r~