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] Inlining vs gimple vs compound expressions


On Thu, 2003-02-27 at 15:34, Daniel Berlin wrote:
> 
> On Thursday, February 27, 2003, at 02:46  PM, law at redhat dot com wrote:
> 
> >
> >
> > Diego/Andrew -- Back when we were in Toronto, we discussed getting rid 
> > of
> > COMPOUND_EXPRs.  Where do we stand on this?
> Without CE's how do you propose we perform insertion, for instance.
> I'm not bitching, i'm asking, since SSAPRE needs to do it.
> 
> I also find it odd that a potential decision that affects other people 
> working on tree-ssa optimizers was not discussed publicly at all yet, 
> and you act as if it's possibly a done deal.
> It's one thing to propose it in toronto, do some work, decide it's not 
> a good idea, and never mention it, but like i said, you act as if this 
> is something already decided one way or the other.  And even if you 
> want to play that way (which isn't particularly nice to do, but hey, 
> whatever) if they are "going away soon", it would be nice to, you know, 
> tell other people involved in development before it just up and 
> happened one day?
> 
> That said, it's not that i like CE's particularly, since right now the 
> restrictions on them make me unable to easily do SSAPRE insertion (in 
> particular, the requirement that the first argument of a CE not be a CE 
> itself), since i can't control where in a CE the trees i want to insert 
> before/after appear.
> Thus, the reason i'm waiting for Andrew's insertion code.
> 

All our discussion entailed was eliminating the dependance on a specific
implementation of linking tree nodes, which is what CE nodes do. Thus
the main drive of the iterators and the inserting/linking routines is to
keep users from ever seeing something like a CE node, which is pure
infrastructure, and half our problem.

If you dont know they exist, we are open to removing them and replacing
them with something better, of which lots of people have ideas on what
would be better. The goal is a competely transparent underlying
structure that can be plug-replaced with something better someday.

Andrew




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