This is the mail archive of the gcc-patches@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: Summary of patches


Jan Hubicka <jh@suse.cz> writes:

> Hi,
> here is list of patches from last two months that still should be
> relevant...
>
> Fomit-frame-pointer:
>   http://gcc.gnu.org/ml/gcc-patches/2004-02/msg01085.html
>     - this is only libjava part, I will send the rest as followup

Looks fine but I would rather a libjava person reviewed it.

>   http://gcc.gnu.org/ml/gcc-patches/2004-01/msg02072.html
>     - trivial, move unnecesary GGC allocation to malloc
>   http://gcc.gnu.org/ml/gcc-patches/2004-01/msg02559.html
>     - avoids expensive indexing of memories in the case we won't use it
>   http://gcc.gnu.org/ml/gcc-patches/2004-01/msg02736.html
>     - fix potential code quality problem brought by my earlier patch.
>   http://gcc.gnu.org/ml/gcc-patches/2004-02/msg00309.html
>     - trivial cleanup

These are OK.

>   http://gcc.gnu.org/ml/gcc-patches/2004-01/msg02371.html

This is also OK; if you feel motivated you might look at mashing the
loops together so we only scan the insn chain once.  (I do not know if
this is possible.)

>   http://gcc.gnu.org/ml/gcc-patches/2004-01/msg02550.html
>     - loglinks in allocpools

Is INSN_UID reset between functions?  If not, that array is going to
get huge and I don't think this is a good idea.

>   http://gcc.gnu.org/ml/gcc-patches/2004-02/msg01979.html
>     - Varrays allocated by xmalloc

The ggc-none implementation of ggc_free is OK; please commit that
separately.

I do not like the part where you change every last instance of
VARRAY_*_INIT.  I would prefer if there were some automatic way to
determine whether or not a varray needed to be allocated via
ggc_alloc.  Better still, figure out some way whereby varrays can be
marked and swept without ever using ggc_alloc (which is not suited to
resizable data structures) for them.

> Per call statistics:
>   (there is only one conflict if the patch is applied to tree-ssa branch so it
>   should not bring any merge problems to Diego)
>   http://gcc.gnu.org/ml/gcc-patches/2004-01/msg02193.html

This is OK provided that you submit a follow-up patch which adds
--enable-statistics to configure.

> Bugfixes:
>   http://gcc.gnu.org/ml/gcc-patches/2004-01/msg02360.html
>   http://gcc.gnu.org/ml/gcc-patches/2004-02/msg01838.html
>     [tree-ssa/tree-profiling] Fix BB merging ICE
>
> SSE:
>   http://gcc.gnu.org/ml/gcc-patches/2004-01/msg00050.html
>     More of the work to get SSE initializers sane.
>
> Tree-ssa
>   http://gcc.gnu.org/ml/gcc-patches/2004-02/msg01417.html
>     [tree-ssa] Elliminate addressof
>   http://gcc.gnu.org/ml/gcc-patches/2004-02/msg00454.html
>     Make DOM1 to cope with pure functions and allows libcall notes
>     for function calls to be elliminated.

I am not qualified to review these.

zw


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