Re: CONST_CALL_P no longer means constant call?

[Jan Hubicka <hubicka at atrey dot karlin dot mff dot cuni dot cz>]

> > Would be CONST_OR_PURE_CALL_P acceptable?
> 
> Okay with me, however it's not my call. :-)
> 
> > I think there is no purpose to waste another bit in rtl to get two macros.
> 
> It useful to have CONST_CALL_P in addition to another macro
> (such as PURE_CALL_P) since more optimizations can be applied
> to a CONST_CALL_P (i.e. a constant call can be moved across
> a memory write, which can't be easily done for a pure call
> since the write may have changed a pointer pointed to by
> a pointer pointed to by a pointer passed to the pure call).

This is not actually so easy in the compiler right now. Even for CONST_CALL_P
call insn no part of compiler actually moves/avoids the stores, since it has
hidden reference to the outgoing args, that may be on the stack, so even
in sched no movements across writes is done. Currently no infrastructure
is present to distinguish outgoing args memory references, So all const
calls are handled as pure calls independently on my pathces.

Currently only bit distinguishing between const and pure calls is in
the cse, and this one don't use CALL insn at all, instead of it reffers
to the LIBCALL notes. This is actually why compiler required almost no
changes to plug in the pure calls.

Perhaps I can modify calls.c (quite easilly) to record every memory location
with parameter to the fusage field, so the true dependencies can be seen
by the scheduler. But then every CONST call will have apperance identical
to PURE call anyway (you will need to verify fusage field before doing
any movement, for pure calls you will hit the scratch memory reference
and give up).

So perhaps renaming CONST_CALL_P to PURE_CALL_P to avoid confussion 
may suffice.
> 
> It don't necessarily require a second bit, CALL_INSN_FUNCTION_USAGE
> may suffice if it's called by the macros though I haven't given it
> a lot of thought.
OK, if you consider it usefull, I will write such macro, but it will
be unused in the compiler for now.
> 
> > Perhaps we can find some better name for it, the const
> > calls are now really just quite a special case of pure calls.
> 
> A very useful special case worth being able to easily identify
> when applying optimizations.
Maybe I am missing something, but as I pointer out above, thinks are
actually not so easy.

Honza