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: [lto] PATCH: fill in code to merge declarations

Mark Mitchell wrote:
> Kenneth Zadeck wrote:
>> Mark Mitchell wrote:
>>> Sandra Loosemore wrote:
>>>> I haven't figured out how to test this yet -- when I try to run more
>>>> than one file through the driver with -x lto -c, it seems to want to
>>>> compile them separately instead of merging them.  Do I need some
>>>> other switch, or has this not been implemented yet?
>>> I will review the patch later today.  However, I think that "-combine"
>>> should work, e.g.:
>>>   gcc -x lto -c -combine a.o b.o
>>> Thanks,
>> i do not see how -combine can work since it will try to gimplify text
>> that has already been gimplified.
> That's an orthogonal issue.  All -combine does is tell the driver to
> pass all of the input "source files" (which, in the case of LTO, are
> what we usually call object files) to the front end at once, rather
> than in separate invocations.  The re-gimplification issue applies
> just as much for a single object file as for multiple object files.
> But, I'm not sure why re-gimplification is a problem, per se.  GIMPLE
> is presumably already valid GIMPLE, so the gimplifier should
> presumably leave it intact.  Are you just concerned about the wasted
> time, or do is there a correctness problem with re-gimplifying?
only correctness.  I am new to this and do know really know how
different all of the dialects interact.  If it will pass thru unchanged,
then it is certainly ok for now.  However, I have things like basic
blocks and the cfg, not a single list of statements and exception
regions already built, so if the gimplifier is going to get stuck on
these we will need to work on this.


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