This is the mail archive of the gcc@gcc.gnu.org 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, 22 Jun 2004 11:24:30 +0200
Jan Hubicka <jh@suse.cz> wrote:

> > > Mark Mitchell <mark@codesourcery.com> writes:
> > > > 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.
> > 
> > I can implement such a function, but it will definitly have a
> > restrictions in a way that it should not touch anything that was not
> > marked as possible entry point.  Objc is using similar hacks as
> > mudflap do BTW (bypassing cgraph and adding functions directly)
> > I will be partly offline till 30th, but I can definitly do it after
> > that.
> 
> And also I can do it before 30th if this gets urgent (like fixing
> 3.4.1, just I won't be able to respond very quickly).

It is not urgent.  I believe I have an alternative way forward (see my
response to Frank).

> I wonder why it broke for you - in the case you are sure that
> everything mudflap function touch is output to the assembly file, the
> hack of bypassing cgraph code should just work for a moment

It's a pass-ordering problem.  mudflap_finish is currently called after
cgraph_optimize ... for each input file.  For IMA, cgraph_optimize
needs to be called just once for all input files.  I hadn't thought of
calling mudflap_finish just once for all input when I sent the original
message.

zw


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