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]

RFA: non-const libcalls



The regstack-1.c test is failing on SPARC, which is a regression from
GCC 2.95.2.

This test-case uses lots of `long double', i.e. 128-bit, arithmetic.
A better compiler could optimize the entire computation away and just
store the right answers, but we don't do that.  We make tons of
libcalls to _Q_add and friends to do all the computations.

The way all of these libcalls work is that you pass three arguments.
The two arithmetic arguments are pointed to by %o0 and %o1.  Then, the
address where you would like the return value placed is stored in 
%sp + 64.

Unfortunately, the libcall-generation goo sets CONST_CALL_P
unconditionally in emit_libcall_block.  This is bogus because the
libcall writes to memory -- namely the output area for the result of
the computation.  The function is definitely not const according to
the definitions in the manual which require that the function not read
from memory pointed to by pointer arguments.

How should we arrange not to set the bit in emit_libcall_block?  Well,
why is the bit being set there at all, instead of when we emit the
call.  This went is as this patch:

  http://gcc.gnu.org/ml/gcc-patches/2000-09/msg00740.html

instigated by Richard and implemented by Bernd.

I suspect that the documentation is slightly wrong for `__attribute__
((const))' since it implies that a function can be const, even if it
writes to memory, as long as that memory is the function return value.
I bet that's not what the various optimizer passes think CONST_CALL_P
means.  True or false?

(Oddly, we do attach CALL_INSN_FUNCTION_USAGE notes indicating that
the *arguments* are clobbered -- even though they aren't.  The TeXinfo
documentation says that CALL_INSN_FUNCTION_USAGE should only have
CLOBBERs for hard registers, but we go ahead and put MEMs there too.
What's up with all that?)

And, do we have to add a CLOBBER to the CALL_INSN_FUNCTION_USAGE for
the memory that is written by the call?

In any case, I plan to revert Bernd's patch, unless I hear an
objection.

Thanks,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com


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