This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Loop optimizer issues
- From: Michael Matz <matz at suse dot de>
- To: David Edelsohn <dje at watson dot ibm dot com>
- Cc: Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>,<gcc at gcc dot gnu dot org>
- Date: Thu, 3 Jul 2003 13:43:29 +0200 (CEST)
- Subject: Re: Loop optimizer issues
Hi,
On Wed, 2 Jul 2003, David Edelsohn wrote:
> I'm sorry, I'm still confused. If you are writing an RTL-based
> loop optimizer, you cannot avoid supporting LIBCALLs.
I think the confusion arises because Zdenek wasn't very clear about what
he exactly means with dropping support for libcalls.
There _will_ be libcall constructs in the RTL the loop optimizer sees
(except if we somewhen really can remove them alltogether from the
compiler, but I don't see that), and hence it obviously has to evalutate
their data flow effects at least.
I guess (and only guess) that Zdenek meant to drop actually moving of
libcalls. Zdenek, could you clarify?
Btw. I would agree that most of those constructs resulting in libcalls
should already have been optimized by tree-ssa, but OTOH I have
difficulties understanding why removing supporting libcalls would be so
much easier to implement. libcalls for REG_NO_CONFLICT blocks are simply
funny multi-pattern statements, and libcalls with just calls, are well,
simply calls. Why is it so much easier to not handle them?
Ciao,
Michael.