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: [tree-ssa] Patch ping


> Hello,
> 
> > > yes, this is from where the idea is taken; you may note that I did not
> > > like it very much, on the other hand, saving 50 bytes on every fifth
> > > statement of a program seemed good enough argument to me.
> > 
> > Do you have some data, for example for PR8361?  
> > 
> > If you can show improvement for real-world code, that'll certainly help
> > your cause. ;-)
> 
> the problem is that I don't know exactly what my cause is :-). I dislike
> the current solution as it is a waste of memory.  I dislike the solution
> I have implemented in this patch, since it is quite dirty.  I like the
> CF_EXPR change I have proposed a while ago, but I seem to be the only
> one :-)

I am second :)  

I do like abstraction and when I first saw the RTL way of expressiong
conditional jumps using set and if_then_else, I felt impressed.

However major use for abstraction is to simplify thinking about the
problem and/or allow code reuse.
After few years, I don't see how this ever helped us.  There is
very little code that is common for usual "if_then_else" and goto
"if_then_else".  Major consumer is constant folding and this is place
that is very wrong.  We do mess up CFG, profile and we had to invent
hack like purge_dead_edges.

So only what the abstraction has brought us is mid confusion of what
type label_ref should be (sometimes they are VOIDmode, sometimes Pmode)
and the fact that we had to write predicates to convert abstractions
into terms we are thinking of (simplejumps, conditionaljumps, tablejumps
and computed jumps)

Similarly for tree-ssa I see little use of re-using COND_EXPR for
control flow.  Usual COND_EXPR on gimple has gimple operands as
operands, but conditioanl jump one does not so they are very diferent
anyway.  (in Generic, this is diferent, the container nature of
COND_EXPR makes ineed perfect sense there)

I must admit I didn't look in detail at your CF_EXPR code, but in
general I tend to like that idea.  I don't feel very strong in this
aspect, but I think it would be nice cleanup and optimization for the
IL.  Other compilers seems to have specialized condjumps constructs too.

Honza
> 
> Zdenek


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