RFA: non-const libcalls

RFA: non-const libcalls

[Mark Mitchell]

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

Re: RFA: non-const libcalls

[Alexandre Oliva]

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?

Re: RFA: non-const libcalls

[Mark Mitchell]

>>>>> "Alexandre" == Alexandre Oliva <aoliva@redhat.com> writes:

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

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

Yes, with a couple of minor changes:

  +for arguments or return values passed by transparent reference) used or

"transparent reference" is not a common term of art, or defined
elsewhere in the manual.  It's GCC-babble. :-)

It's also weird to say a return value is passed.

How about:

  expressions that denote hard registers and @code{MEM}s.  The
  @code{MEM}s will typically be stack slots used for arguments 
  that are passed on the stack.  If the function returns its  
  value in memory (as with calling conventions where structures
  are returned in memory), the @code{MEM} for the return value
  will be present as well.

And that suggests that (although you didn't explicitly answer), that
there *should* be a CLOBBER for the return value -- even though
expand_libcall_value_1 isn't adding one.

Finally, 

  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.

this bit didn't make sense to me before, and it still doesn't now.
What does it mean about "during" vs. "after"?  How can something be
clobbered by the instruction after it finishes execution?

I think there's an important idea in here, but it's not coming out
with these words.  Can you expand on that a little and/or provide an
example that shows what assumptions you can make it the two different
cases?

Good documentation is very important.  Thanks for doing this!

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

Re: RFA: non-const libcalls

[Richard Henderson]

On Tue, May 08, 2001 at 01:13:38AM -0700, Mark Mitchell wrote:
> Unfortunately, the libcall-generation goo sets CONST_CALL_P
> unconditionally in emit_libcall_block.

No it doesn't.  True, it defaults to const for LCT_CONST,
but it is supposed to get cleared here:

  /* If this kind of value comes back in memory,
     decide where in memory it should come back.  */
  if (outmode != VOIDmode && aggregate_value_p (type_for_mode (outmode, 0)))
    {
...
      /* This call returns a big structure.  */
      flags &= ~(ECF_CONST | ECF_PURE);
    }

But clearly this isn't happening, as otherwise we wouldn't get here:

  if ((flags & (ECF_CONST | ECF_PURE))
      && valreg != 0 && GET_CODE (valreg) != PARALLEL)
    {
...
      emit_libcall_block (insns, temp, valreg, note);

> (Oddly, we do attach CALL_INSN_FUNCTION_USAGE notes indicating that
> the *arguments* are clobbered -- even though they aren't.

They might be.  That memory is available to the callee as a
home for that varaible.  If the variable is modified within
the callee, it is allowed to spill the value there instead 
of in a new spot in the stack frame.

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

Huh.  I could have sworn it mentioned memories.  Certainly this
practice was not introduced recently...


r~

Re: RFA: non-const libcalls

[Richard Henderson]

On Tue, May 08, 2001 at 12:48:54PM -0700, Richard Henderson wrote:
> But clearly this isn't happening, as otherwise we wouldn't get here:
> 
>   if ((flags & (ECF_CONST | ECF_PURE))
>       && valreg != 0 && GET_CODE (valreg) != PARALLEL)
>     {
> ...
>       emit_libcall_block (insns, temp, valreg, note);

We don't.  The errant emit_libcall_block is invoked in the
caller, expand_binop.

Short term, you should probably revert Bernd's patch.
Long term, we should revamp all of this nonsense.


r~

Re: RFA: non-const libcalls

[Mark Mitchell]

>>>>> "Richard" == Richard Henderson <rth@redhat.com> writes:

    Richard> Short term, you should probably revert Bernd's patch.
    Richard> Long term, we should revamp all of this nonsense.

Thank you for investigating.

  > (Oddly, we do attach CALL_INSN_FUNCTION_USAGE notes indicating that
  > the *arguments* are clobbered -- even though they aren't.

  They might be.  That memory is available to the callee as a
  home for that varaible.  If the variable is modified within
  the callee, it is allowed to spill the value there instead 
  of in a new spot in the stack frame.

Right.  I meant that for some particular functions, we know they won't
do this, and we could optimize better by knowing that.  But, certainly
the current behavior is conservative, which is good.

I agree about the revamping.  I don't think emit_libcall_block should
be the one deciding which calls are `const'; that's a property of the
function itself.  We ought to have something in the optab that
indicates that.

Bootstrapped on sparc-sun-solaris2.8, applied on the branch and on the
mainline.

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

2001-05-11  Mark Mitchell  <mark@codesourcery.com>

	* optabs.c (emit_libcall_block): Don't mark calls as CONST_CALL_P.

Index: optabs.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/optabs.c,v
retrieving revision 1.87.4.1
diff -c -p -r1.87.4.1 optabs.c
*** optabs.c	2001/04/14 03:32:47	1.87.4.1
--- optabs.c	2001/05/11 15:13:13
*************** emit_libcall_block (insns, target, resul
*** 2813,2826 ****
    /* look for any CALL_INSNs in this sequence, and attach a REG_EH_REGION
       reg note to indicate that this call cannot throw or execute a nonlocal
       goto (unless there is already a REG_EH_REGION note, in which case
!      we update it).  Also set the CONST_CALL_P flag.  */
  
    for (insn = insns; insn; insn = NEXT_INSN (insn))
      if (GET_CODE (insn) == CALL_INSN)
        {
  	rtx note = find_reg_note (insn, REG_EH_REGION, NULL_RTX);
  
- 	CONST_CALL_P (insn) = 1;
  	if (note != 0)
  	  XEXP (note, 0) = GEN_INT (-1);
  	else
--- 2813,2825 ----
    /* look for any CALL_INSNs in this sequence, and attach a REG_EH_REGION
       reg note to indicate that this call cannot throw or execute a nonlocal
       goto (unless there is already a REG_EH_REGION note, in which case
!      we update it).  */
  
    for (insn = insns; insn; insn = NEXT_INSN (insn))
      if (GET_CODE (insn) == CALL_INSN)
        {
  	rtx note = find_reg_note (insn, REG_EH_REGION, NULL_RTX);
  
  	if (note != 0)
  	  XEXP (note, 0) = GEN_INT (-1);
  	else

Re: RFA: non-const libcalls

[Alexandre Oliva]

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

>>>>>> "Alexandre" == Alexandre Oliva <aoliva@redhat.com> writes:
>>> 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?

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

> Yes, with a couple of minor changes:

> I think there's an important idea in here, but it's not coming out
> with these words.  Can you expand on that a little and/or provide an
> example that shows what assumptions you can make it the two different
> cases?

How's this?  Ok to install?

Re: RFA: non-const libcalls

[Richard Henderson]

On Sat, May 12, 2001 at 09:14:09AM -0300, Alexandre Oliva wrote:
>  These
> +@code{MEM}s are used only in @code{LIBCALL}s, because they don't
> +introduce basic blocks.

Err, no.  Basic blocks have nothing to do with this.  These
mems are used only on CONST_CALL_P libcalls.

> +A register or memory region specified in a @code{clobber} in this list
> +is modified @emph{after} the execution of the @code{call_insn} (i.e.,
> +it's preserved during the execution of the @code{call_insn} itself, but
> +the called function is assumed to clobber it), while a register
> +specified in a @code{clobber} in the body of the @code{call_insn} is
> +clobbered before the insn completes execution (i.e., it's modified
> +before the callee starts executing).

This distinction is meaningless.  The call pattern is atomic as far
as the compiler is concerned.


r~

Re: RFA: non-const libcalls

[Alexandre Oliva]

On May 12, 2001, Richard Henderson <rth@redhat.com> wrote:

> On Sat, May 12, 2001 at 09:14:09AM -0300, Alexandre Oliva wrote:
>> These
>> +@code{MEM}s are used only in @code{LIBCALL}s, because they don't
>> +introduce basic blocks.

> Err, no.  Basic blocks have nothing to do with this.  These
> mems are used only on CONST_CALL_P libcalls.

My recollection of this is fuzzy.  The port I worked on that used lots
of by-reference arguments to libcalls faced problems of having stores
into the stack slots used to pass arguments deleted because of some
pass that looked for dead stores.  I'm pretty sure there was no
problem in case the stores came before a regular call because this
thing operated only within basic blocks, but in the case of libcalls,
it failed, because it ended up deciding the store was dead if it
happened to be in the exit block.  Or something like that.  Do you
recognize this pattern of keeping track of stores looking for dead
ones?  Could you point me at the pass or chunk of code that does that,
to refresh my memory?  I poked around for a while, found something in
flow that seemed to be what I was looking for, but I'm not sure.

>> +A register or memory region specified in a @code{clobber} in this list
>> +is modified @emph{after} the execution of the @code{call_insn} (i.e.,
>> +it's preserved during the execution of the @code{call_insn} itself, but
>> +the called function is assumed to clobber it), while a register
>> +specified in a @code{clobber} in the body of the @code{call_insn} is
>> +clobbered before the insn completes execution (i.e., it's modified
>> +before the callee starts executing).

> This distinction is meaningless.  The call pattern is atomic as far
> as the compiler is concerned.

Ok to remove the original paragraph, then?

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

Re: RFA: non-const libcalls

[Richard Henderson]

On Sat, May 12, 2001 at 03:21:56PM -0300, Alexandre Oliva wrote:
> I'm pretty sure there was no problem in case the stores came before
> a regular call because this thing operated only within basic blocks,

No.  There was no problem on regular calls because they are 
assumed to read and write all memory.  From propagate_one_insn,

          /* Non-constant calls clobber memory.  */
          if (! CONST_CALL_P (insn))
            {
              free_EXPR_LIST_list (&pbi->mem_set_list);
              pbi->mem_set_list_len = 0;
            }

> Could you point me at the pass or chunk of code that does that,
> to refresh my memory?

The tracking is done in mark_set_1 and mark_used_regs.  The
killing is done in insn_dead_p.

> Ok to remove the original paragraph, then?

Yes.



r~

Re: RFA: non-const libcalls

[Mark Mitchell]

That's great!

Thanks,

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

Re: RFA: non-const libcalls

[Mark Mitchell]

>>>>> "Richard" == Richard Henderson <rth@redhat.com> writes:

    Richard> This distinction is meaningless.  The call pattern is
    Richard> atomic as far as the compiler is concerned.

Ah, even better.  I was confused by this, which is why asked Alexandre
to explain it -- but if there's no actual distinction, then we can
just remove the paragraph entirely, which will confuse me even
less. :-)

Thanks,

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

Re: RFA: non-const libcalls

[Alexandre Oliva]

On May 12, 2001, Richard Henderson <rth@redhat.com> wrote:

> On Sat, May 12, 2001 at 03:21:56PM -0300, Alexandre Oliva wrote:
>> I'm pretty sure there was no problem in case the stores came before
>> a regular call because this thing operated only within basic blocks,

> No.  There was no problem on regular calls because they are 
> assumed to read and write all memory.

>           /* Non-constant calls clobber memory.  */
>           if (! CONST_CALL_P (insn))

Hmm...  So we probably still have a problem with regular function
calls declared with attribute const, don't we?  We should probably be
emitting CALL_INSN_FUNCTION_USAGE notes for arguments passed by
reference to non-libcall const functions, shouldn't we?

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

Re: RFA: non-const libcalls

[Alexandre Oliva]

On May 13, 2001, Alexandre Oliva <aoliva@redhat.com> wrote:

> On May 12, 2001, Richard Henderson <rth@redhat.com> wrote:
>> On Sat, May 12, 2001 at 03:21:56PM -0300, Alexandre Oliva wrote:
>>> I'm pretty sure there was no problem in case the stores came before
>>> a regular call because this thing operated only within basic blocks,

>> No.  There was no problem on regular calls because they are 
>> assumed to read and write all memory.

>> /* Non-constant calls clobber memory.  */
>> if (! CONST_CALL_P (insn))

> Hmm...  So we probably still have a problem with regular function
> calls declared with attribute const, don't we?  We should probably be
> emitting CALL_INSN_FUNCTION_USAGE notes for arguments passed by
> reference to non-libcall const functions, shouldn't we?

Anyway, ok to install this so far?

Re: RFA: non-const libcalls

[Richard Henderson]

On Sun, May 13, 2001 at 10:06:03PM -0300, Alexandre Oliva wrote:
> 	* rtl.texi (CALL_INSN_FUNCTION_USAGE): Note that (and when) it may
> 	contain MEMs.  Remove useless distinction about clobbering
> 	registers.

Ok.


r~

Re: RFA: non-const libcalls

[Richard Henderson]

On Sun, May 13, 2001 at 07:45:57PM -0300, Alexandre Oliva wrote:
> Hmm...  So we probably still have a problem with regular function
> calls declared with attribute const, don't we?  We should probably be
> emitting CALL_INSN_FUNCTION_USAGE notes for arguments passed by
> reference to non-libcall const functions, shouldn't we?

Maybe.  It might already be taken care of.  I don't remember.


r~