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: [tree-ssa] Work around for an unfortunate fold-const vs.tree-optimizer interaction


On Mon, 2003-11-10 at 16:22, Diego Novillo wrote:
> On Thu, 2003-11-06 at 16:30, Andrew MacLeod wrote:
> 
> > Ona  side note, Im about to turn GIMPLE back into GENERIC in
> > SSA->normal, but only as far as expressions go... ie, allowing something
> > more than a two operand expression.  So we can get a string of
> > assignments into temporaries that are only used once turned back into an
> > expression. ie:
> I was thinking today that perhaps we may want to think about moving the
> tree->RTL expander to an earlier spot.  What if instead of going into
> normal form like we do now, we went directly from GIMPLE trees in SSA
> form into RTL?
> 
> This would be a big change, for sure, but since all the data flow
> information is there, in theory we would not need to combine trees nor
> generate them in normal form.
> 
> It could also get unpleasantly ugly, though.  Thoughts?

Im not sure I'd want to go straight to RTL. there are various cleanup
type things we do, and there my be other types of optimizations we want
to do. Perhaps we want to inline optimized trees, so you want to keep
the trees around...

I do wonder if we ought to make the expanders aware of the concept of an
SSA_NAME though... As Jan pointed out it could reduce some of our
temporaries... So we leave selected SSA_NAME temporaries as SSA_NAMEs
and they get mapped directly to registers like a DECL.  Im still
thinking about it. SSA->normal would still insert the copies, etc.

Andrew


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