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.
