Loop optimizer issues

[Michael Matz]

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.