Re: mudflap versus cgraph

[Zack Weinberg <zack at codesourcery dot com>]

Mark Mitchell <mark@codesourcery.com> writes:

> Zack Weinberg wrote:
>
>>mudflap has a pass-ordering conflict which I cannot figure out how
>>to resolve.  mudflap_finish() generates and emits a function
>>(calling tree_rest_of_compilation directly) after cgraph_optimize()
>>has been called, which is wrong.  But it has to do that, because the
>>set of items to be registered with the mudflap runtime at static
>>construction time is only determined at final assembly output time
>>-- the callers of mudflap_enqueue_decl/mudflap_enqueue_constant are
>>in varasm.c.
>>
>
> I think that's the problem.  In the cgraph world, the arbiter of
> what things are needed is cgraph itself.  There should be a hook
> that cgraph calls to add additional functions -- after it has
> already decided on everything else.

Right (although there is a concern about later optimization passes
eliminating the need for some variable or (more likely) constant).
But that's way more invasive than I want right now.

> Is this for your IMA fixes?  It might be that mudflap has to be
> broken for a while, while IMA gets fixed...

Yeah, it's for IMA.  If it's mudflap's turn to be broken for awhile I
don't have a problem with that, but I didn't want to spring it on
people with no notice.

zw