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: birthpoints in rtl.


> 
> Not libcalls, but libcall *notes*.
> 
> >  This exist so we can effectivly remove
> >  blocks of code in dead code removal and do some other changes, but I
> >  don't see how they can be less friendly to FUD than they are to DU/UD.
> >  Sure the optimization has to care to not break the extra invariant that
> >  libcalls stay independent, but that is.
> 
> The extra care is the problem.  To be fair, the problem is manageable
> (see the whole DCE vs. libcall notes thread from last year) but it
> adds a lot of complexity and defeats the benefits of having FUD

I see.  This should not get that worse with FUD.
> chains.  Basically the same problem as the issues we had for RTL SSA.
> See these threads:
> 
> http://gcc.gnu.org/ml/gcc-patches/2000-07/msg01152.html
> http://gcc.gnu.org/ml/gcc-patches/2000-07/msg01174.html).

The point I wanted to make is that FUD is more firendly to RTL than true
rewriting SSA and it general it should not be any worse than DU/UD.  In
particular the read-write constructs, like subregs, are not issue and
neither are the unssa problems related to libcalls disucssed in the
thread you point to. This does not imply that it would not be great to
eliminate those issues too.

In the CFG branch time, I had working FUD implementation on RTL and
updated the existing constant propagation and dead code RTL pass of that
time.  The plan was given up in favor of midlevel RTL idea since it
didn't seem to had chance to get to mainline and it was clear we needed
some sort of higher level IL.  I also got midlevel RTL working with both
FUD and/or rewriting SSA form on i386 but I am happy it is gone in
favour of tree-SSA.
> 
> I could also start a rant here about how tree-ssa was supposed to make
> libcall notes obsolete, how much better things already would be today
> even without libcall notes if you compare it to the pre-tree-ssa era,
> and how GCC once again chooses irrational conservatism over reaping
> the fruits of all the tree-ssa work -- but that's *really* orthogonal
> to this thread, so I won't ;-)

Yes, it is.  I fully agree and I would love to see libcalls going even
if it would mean some degradation in side corners. I will try to patch
periodic testers to see how much real life difference they make.

Honza


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