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