This is the mail archive of the
mailing list for the GCC project.
Re: [tree-ssa PATCH] Pick memory consumption low hanging fruit
- From: Andrew MacLeod <amacleod at redhat dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: Steven Bosscher <steven at lr dot tudelft dot nl>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: 17 Nov 2003 11:59:25 -0500
- Subject: Re: [tree-ssa PATCH] Pick memory consumption low hanging fruit
- References: <200311171625.hAHGP0Lj023320@speedy.slc.redhat.com>
On Mon, 2003-11-17 at 11:25, firstname.lastname@example.org wrote:
> In message <Pine.HPP.3.91.1031117115419.11610Aemail@example.com>, S
> teven Bosscher writes:
> > This message is in MIME format. The first part should be readable text,
> > while the remaining parts are likely unreadable without MIME-aware tools.
> > Send mail to firstname.lastname@example.org for more info.
> >Content-Type: TEXT/PLAIN; charset=US-ASCII
> >We can safely use lang_flags for SSA form specific tree nodes.
> >Bootstrapped-'n'-tested all tree-ssa front ends on i686-pc-linux-gnu,
> >OK to commit?
> >2003-11-17 Steven Bosscher <email@example.com>
> > * tree.h (SSA_NAME_OCCURS_IN_ABNORMAL_PHI): Use lang_flag_6
> > from tree_common.
> > (struct tree_ssa_name): Remove `occurs_in_abnormal_phi' field.
> > (PHI_REWRITTEN): Also use lang_flag_6 from tree_common.
> > (struct tree_phi_node): Remove `rewritten' field.
> I would *much* prefer we take a systematic approach to this problem --
> ie, rather than moving one bit around at a time, let's think a little
> longer term about the entire scheme for annotations, pass-local flags
> and the like. Moving bits into the tree common flags right now is
> IMHO premature.
Yes, we need to look at the entire issue of moving annotations into the
correct nodes, and what information in the annotations are
non-overalpping, etc. all that at once. Doesn't that sound like fun?
It seems like it might be best done post-merge with mainline due to the
conflicts and stuff it would cause when trying to do reverse merges to
the branch... I susp[ect thats half the reason it was done this way in
the first place :-).
We also need to look at the memory consuption and whats actually in
those nodes right now.