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]

Re: RFA: non-const libcalls


On May  8, 2001, Mark Mitchell <mark@codesourcery.com> wrote:

> 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?

Perhaps passing it a boolean flag with the result of:
(mem_value != 0 && struct_value_rtx != 0 && ! pcc_struct_value)

> 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?

The USEs were added to prevent flow from considering dead the stores
into stack slots used to hold arguments passed by transparent
reference, and the clobbers prevent us from assuming such arguments
from remaining unchanged when they're not callee-copied.  I'm not 100%
sure they're necessary, but they're definitely sound.

It seems that I forgot to update the docs, though.  Ok to install?
Branch and mainline?

Index: gcc/ChangeLog
from  Alexandre Oliva  <aoliva@redhat.com>

	* rtl.texi (CALL_INSN_FUNCTION_USAGE): Note that (and when) it may
	contain MEMs.

Index: gcc/rtl.texi
===================================================================
RCS file: /cvs/gcc/egcs/gcc/rtl.texi,v
retrieving revision 1.38
diff -u -p -r1.38 rtl.texi
--- gcc/rtl.texi 2001/04/19 19:44:12 1.38
+++ gcc/rtl.texi 2001/05/08 09:23:33
@@ -2523,13 +2523,14 @@ unpredictably.
 accessed in the same way and in addition contain a field
 @code{CALL_INSN_FUNCTION_USAGE}, which contains a list (chain of
 @code{expr_list} expressions) containing @code{use} and @code{clobber}
-expressions that denote hard registers used or clobbered by the called
-function.  A register specified in a @code{clobber} in this list is
-modified @emph{after} the execution of the @code{call_insn}, while a
-register in a @code{clobber} in the body of the @code{call_insn} is
-clobbered before the insn completes execution.  @code{clobber}
-expressions in this list augment registers specified in
-@code{CALL_USED_REGISTERS} (@pxref{Register Basics}).
+expressions that denote hard registers and @code{MEM}s (stack slots used
+for arguments or return values passed by transparent reference) used or
+clobbered by the called function.  A register specified in a
+@code{clobber} in this list is modified @emph{after} the execution of
+the @code{call_insn}, while a register in a @code{clobber} in the body
+of the @code{call_insn} is clobbered before the insn completes
+execution.  @code{clobber} expressions in this list augment registers
+specified in @code{CALL_USED_REGISTERS} (@pxref{Register Basics}).
 
 @findex code_label
 @findex CODE_LABEL_NUMBER

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

I'm not sure it's necessary.  I don't see a reason why we'd store
something in there that would be expected to survive the function call
without the clobber.  But adding it wouldn't hurt, and may save us
from obscure bugs in the future.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

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