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: Unreviewed patches

Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz> writes:

> Hello,
> a few of my patches got (mostly) silently ignored last month; this is a bit
> unpleasant as some of them won't be suitable for stage 2 and the other
> ones block my further work. Could you please have a look at some of
> them please?
>   -- rtlopt branch merge patches

Too big and hairy for me.  You might want to run the gcov stuff by
Nathan Sidwell, he wrote most of the current implementation.

>   wrong new files atached here, fixed by
>   -- foundation for toplevel driver cleanup

I feel that this is still trying to do too much at once.  Suggested
plan of attack:

Patch 0, rip all the dump-file code out of toplev.c into its own
file, call it rtl-dump.c.

Patch 1..n, one optimizer pass at a time, either modify the existing
entry point from toplev.c (preferred) or create a new entry point (if
the existing interface is needed elsewhere) to match a restricted
signature [bool (*)(void) suggested, where the return value means
'changed something'].  Push all the surrounding paraphernalia from
rest_of_compilation -- timevar pushes and pops, dump file handling,
etc -- down into the entry point function.  The entry point functions
should go in the same file as the rest of the pass, not in a separate

Patch n+1 then introduces passes.def and converts rest_of_compilation
to a loop over a vector of function pointers.

>   -- fix for latent bug in liveness analysis

This looks like a problem worth fixing, but (a) it's not obvious to me
why we are starting from nonempty sets in the first place, (b) it's
not obvious why your fallback strategy is guaranteed to terminate, and
(c) I'd like to see a test case that triggers nontermination.

>   -- fix for ugly code generated for small array initializers

Feels like papering over the underlying problem; however, the
underlying problem is probably that we have ADDRESSOF in the first
place...  I'd like a reaction from someone better familiar with the
issues here.

>   -- split log links creation from flow.c

Looks to *me* like a good cleanup.  But, since Richard objected, I
would rather hear what he thought of your response to his objection.

(create_log_links is only ever called with NULL parameter -- why is
that parameter present?)


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