This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: mudflap versus cgraph

On Tue, Jun 22, 2004 at 10:54:23AM -0700, Zack Weinberg wrote:
> What should it look like?

The cgraph hook would take an expression to accumulate in the set of
cdtors to run for the function.  It would scan this expression
immediately and add symbols involved to the callgraph.

> All existing examples of synthetic function
> creation involve calling a few language-dependent hooks (if nothing
> else, the start_function and finish_function equivalents).

You'll find that start_function/finish_function has more to do with
scope management than anything else these days.  Since the cdtor
function has no arguments, and no local variables, it needn't do
any scope management.

The minimum required is like

	decl = build_decl (FUNCTION_DECL, name, 
			   build_function_type (void_type_node,
	TREE_STATIC (decl) = 1;
	TREE_PUBLIC (decl) = !targetm.have_ctors_dtors;
	DECL_RESULT (decl) = build_decl (RESULT_DECL, NULL, void_type_node);
	allocate_struct_function (decl);
	DECL_SAVED_TREE (decl) = alloc_stmt_list ();

then for each expression

	append_to_statement_list (expr, &DECL_SAVED_TREE (decl));


	current_function_decl = decl;
	cfun = DECL_STRUCT_FUNCTION (decl);
	gimplify_function_tree (decl);
	tree_rest_of_compilation (decl, 0);

You might find that the scanning code works better if it only works
on gimple.  If so, you can gimplify each expression individually.
Something like

	current_function_decl = decl;
	cfun = DECL_STRUCT_FUNCTION (decl);
	walk_tree (&expr, copy_if_shared_r, NULL, NULL);
	push_gimplify_context ();
	gimplify_stmt (&expr);
	pop_gimplify_context (NULL);


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]