[patch] [struct-reorg] port to ssa - 47% on art on ppc
Wed Aug 16 20:17:00 GMT 2006
On 8/16/06, Olga Golovanevsky <OLGA@il.ibm.com> wrote:
> "Richard Guenther" <firstname.lastname@example.org> wrote on 16/08/2006
> > On 8/16/06, Olga Golovanevsky <OLGA@il.ibm.com> wrote:
> > > Dan,
> > >
> > > Thank you for comments. Preparing fixes.
> > >
> > > Daniel Berlin <email@example.com> wrote on 15/08/2006 15:54:46:
> > >
> > > >
> > > > Please instead use call_expr_flags (<CALL_EXPR>) & ECF_MALLOC
> > >
> > > thank you for tip. I only wonder whether ECF_MALLOC stands for all
> > > allocation functions, i.e. malloc, calloc, realloc, xmalloc, or only
> > > malloc?
> > It only says the function has malloc behavior in that it returns a
> > pointer that
> > does not alias with any other memory. So
> > /* Nonzero if this is a call to malloc or a related function. */
> > #define ECF_MALLOC 4
> > is not really useful documentation ;) flags_from_decl_or_type has
> > the slightly
> > more informative
> > /* The function exp may have the `malloc' attribute. */
> > if (DECL_IS_MALLOC (exp))
> > flags |= ECF_MALLOC;
> ok, I see.
> So DECL_IS_MALLOC is actually defines family of functions that return
> if (TREE_CODE (*node) == FUNCTION_DECL
> && POINTER_TYPE_P (TREE_TYPE (TREE_TYPE (*node))))
> DECL_IS_MALLOC (*node) = 1;
> I can use it for rough identification, but in order to analyze closely
> I still need this ugly
> if (strcmp (IDENTIFIER_POINTER (DECL_NAME (fn_decl)),
> "malloc") == 0)
> unless you say me there is more elegant way.
You should use DECL_FUNCTION_CODE on the function decl and
see if it matches BUILT_IN_MALLOC (or others, see gcc/builtins.def).
This is because a user might override malloc with something different
and still set the malloc attribute on it.
> I need to distinguish between these functions because their trees
> have different structures, and I need to go inside and analyze their
> (For example, calloc has two parameters, and malloc only one)
There's at least BUILT_IN_CALLOC and BUILT_IN_ALLOCA.
> thanks you a lot,
> > Richard.
More information about the Gcc-patches