Introduced in revision 187459.

What's it actually trying to access, and failing? Is dest NULL or something?

On 16-May-12, at 6:30 PM, bernds at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53381
>
> --- Comment #2 from Bernd Schmidt <bernds at gcc dot gnu.org>  
> 2012-05-16 22:30:53 UTC ---
> What's it actually trying to access, and failing? Is dest NULL or  
> something?


It's call_set that's NULL.

(gdb) p debug_rtx (insn)
(call_insn 563 562 565 41 (parallel [
             (set (reg:SI 4 %r4)
                 (reg:SI 19 %r19))
             (set (reg:SI 28 %r28)
                 (call (mem:SI (symbol_ref/v:SI ("@memcpy") [flags  
0x241] <function_decl 0x4163e980 memcpy>) [0 S4 A32])
                     (const_int 16 [0x10])))
             (clobber (reg:SI 1 %r1))
             (clobber (reg:SI 2 %r2))
             (use (reg:SI 4 %r4))
             (use (reg:SI 19 %r19))
             (use (const_int 0 [0]))
         ]) ../../../gcc/libgcc/unwind-dw2.c:1028 206  
{call_val_symref_pic}
      (expr_list:REG_RETURNED (reg/v/f:SI 20 %r20 [orig:99 new_rs ]  
[99])
         (expr_list:REG_DEAD (reg:SI 26 %r26)
             (expr_list:REG_DEAD (reg:SI 25 %r25)
                 (expr_list:REG_DEAD (reg:SI 24 %r24)
                     (expr_list:REG_UNUSED (reg:SI 28 %r28)
                         (expr_list:REG_EH_REGION (const_int 0 [0])
                             (nil)))))))
     (expr_list:REG_CC_SETTER (set (reg:SI 28 %r28)
             (reg:SI 26 %r26))
         (expr_list:REG_CC_SETTER (use (reg:SI 24 %r24))
             (expr_list:REG_CC_SETTER (use (reg:SI 25 %r25))
                 (expr_list:REG_CC_SETTER (use (reg:SI 26 %r26))
                     (nil))))))

--
John David Anglin	dave.anglin@bell.net

Created attachment 27427 [details]
Candidate patch

Ok, seriously weird call insns. If you can fix that in the port, it'll benefit from the optimization. Otherwise, try the following which disables it for targets with strange call insns.

I won't be able to check this in until Monday; I think if it passes testing on your machine you can either check it in as obvious or wait a few days.

On 16-May-12, at 7:14 PM, bernds at gcc dot gnu.org wrote:

> Ok, seriously weird call insns. If you can fix that in the port,  
> it'll benefit
> from the optimization. Otherwise, try the following which disables  
> it for
> targets with strange call insns.

Agreed.  In PIC, the runtime architecture mandates that the PIC register
is saved and restored across function calls.  It's been quite a few  
years
since the current scheme was worked out.  There were previous  
implementations
where the save wasn't part of the call but there were always  
occasional cases
where the restore was lost resulting in wrong code.  Part of the  
problem is
not all uses of the PIC register are exposed prior to reload.  There are
splitters to optimize things a bit after reload.

I'm reluctant to change the current implementation because the situation
is quite tricky.

Dave
--
John David Anglin	dave.anglin@bell.net

On 16-May-12, at 7:14 PM, bernds at gcc dot gnu.org wrote:

> Ok, seriously weird call insns. If you can fix that in the port,  
> it'll benefit
> from the optimization. Otherwise, try the following which disables  
> it for
> targets with strange call insns.

I'll try this on the weekend.  It may be fairly easy.

--
John David Anglin	dave.anglin@bell.net

Can't you instead of using single_set just find the single set with GET_CODE (SET_SRC (set)) == CALL (and only punt if there is none or more than one)?
That would handle e.g. the AVX marked call or this one just fine...

Note that e.g. dse.c (scan_insn) handles the AVX mem* just fine, but won't handle this PA pattern because (set (reg) (call ...)) isn't the first thing in the parallel.  Any reason for that?
          rtx call = PATTERN (insn);
          if (GET_CODE (call) == PARALLEL)
            call = XVECEXP (call, 0, 0);
          if (GET_CODE (call) == SET)
            call = SET_SRC (call);
          if (GET_CODE (call) == CALL
              && MEM_P (XEXP (call, 0))
              && GET_CODE (XEXP (XEXP (call, 0), 0)) == SYMBOL_REF)

On 5/17/2012 2:48 AM, jakub at gcc dot gnu.org wrote:
> Note that e.g. dse.c (scan_insn) handles the AVX mem* just fine, but won't
> handle this PA pattern because (set (reg) (call ...)) isn't the first thing in
> the parallel.  Any reason for that?
There is no reason other than the RTL was trying to reflect the save and 
restore of the
PIC register.  I hacked the call patterns to completely hide the 
handling of the PIC register
until they are split after reload.  So far, testing looks ok.

For DSE it would be enough if just the call was first in the parallel and the currently first set came after it.  All sets in a parallel happen at the same time...

duplicate btw.

*** This bug has been marked as a duplicate of bug 53373 ***