Re: [PATCH][ PR rtl-optimization/79286] Drop may_trap_p exception to testing dominance in update_equiv_regs

[Bernd Edlinger <bernd.edlinger@hotmail.de>]

On 04/28/17 21:14, Bernd Edlinger wrote:
> On 04/28/17 20:46, Jeff Law wrote:
>> On 04/28/2017 11:27 AM, Bernd Edlinger wrote:
>>>>
>>>
>>> Yes I agree, that is probably not worth it.  So I could try to remove
>>> the special handling of PIC+const and see what happens.
>>>
>>> However the SYMBOL_REF_FUNCTION_P is another story, that part I would
>>> like to keep: It happens quite often, already w/o -fpic that call
>>> statements are using SYMBOL_REFs to ordinary (not weak) function
>>> symbols, and may_trap returns 1 for these call statements wihch is IMHO
>>> wrong.
>> Hmm, thinking more about this, wasn't the original case a PIC referrence
>> for something like &x[BIGNUM].
>>
>> Perhaps we could consider a PIC reference without other arithmetic as
>> safe.  That would likely pick up the SYMBOL_REF_FUNCTION_P case you want
>> as well good deal many more PIC references as non-trapping.
>>
>> Jeff
>
> Yes, IIRC it was a UNSPEC_GOTOFF.
> I think it comes from legitimize_pic_address:
>
>       if (GET_CODE (addr) == PLUS)
>           {
>             new_rtx = gen_rtx_UNSPEC (Pmode, gen_rtvec (1, XEXP (addr, 0)),
>                                       UNSPEC_GOTOFF);
>             new_rtx = gen_rtx_PLUS (Pmode, new_rtx, XEXP (addr, 1));
>           }
>         else
>           new_rtx = gen_rtx_UNSPEC (Pmode, gen_rtvec (1, addr),
> UNSPEC_GOTOFF);
>
>       new_rtx = gen_rtx_CONST (Pmode, new_rtx);
>
> and it is somehow special, because it is a static value
> that is accessed relative to the PIC register,
> we know the bounds of the static object, the form of the
> RTL may vary dependent on the target, of course, if the
> form is not recognized, may_trap_p would behave as if
> the PIC+const case was not there.  Maybe I could check
> that the SYMBOL_REF is a local value?
>
> Everything else is accessing the address of an external
> variable, this is arranged by the linker and should be safe.
>
>

Reading a bit further in legitimize_pic_address I see this:

           new_rtx = gen_rtx_UNSPEC (Pmode, gen_rtvec (1, addr), 
UNSPEC_GOT);
           new_rtx = gen_rtx_CONST (Pmode, new_rtx);
           if (TARGET_64BIT)
             new_rtx = force_reg (Pmode, new_rtx);
           new_rtx = gen_rtx_PLUS (Pmode, pic_offset_table_rtx, new_rtx);
           new_rtx = gen_const_mem (Pmode, new_rtx);
           set_mem_alias_set (new_rtx, ix86_GOT_alias_set ());

and gen_const_mem sets MEM_NOTRAP_P
furthermore in may_trap_p_1 we have:

      case MEM:
       /* Recognize specific pattern of stack checking probes.  */
       if (flag_stack_check
           && MEM_VOLATILE_P (x)
           && XEXP (x, 0) == stack_pointer_rtx)
         return 1;
       if (/* MEM_NOTRAP_P only relates to the actual position of the memory
              reference; moving it out of context such as when moving code
              when optimizing, might cause its address to become 
invalid.  */
           code_changed
           || !MEM_NOTRAP_P (x))
         {
           HOST_WIDE_INT size = MEM_SIZE_KNOWN_P (x) ? MEM_SIZE (x) : 0;
           return rtx_addr_can_trap_p_1 (XEXP (x, 0), 0, size,
                                         GET_MODE (x), code_changed);
         }

       return 0;


So it is quite possible that the real pic refernces will not
go into rtx_addr_can_trap_p_1 at all.


Bernd.