On 04/23/2017 05:54 AM, Bernd Edlinger wrote:
Hi Jeff,
this patch tries to fix the handling of pic_offset_rtx +
const(unspec(symbol_ref)+ const_int) in may_trap_p,
and restores the original state of affairs in update_equiv_regs.
What do you think is it OK to extract the symbol_ref out
of the unspec in this way, or is does it need a target hook?
Patch works at least for x86_64 and arm.
Is it OK for trunk?
Bernd.
patch-pr79286.diff
2017-04-23 Bernd Edlinger<bernd.edlin...@hotmail.de>
rtl-optimizatoin/79286
* ira.c (update_equiv_regs): Revert to using may_tap_p again.
* rtlanal.c (rtx_addr_can_trap_p_1): SYMBOL_REF_FUNCTION_P can never
trap. Extract constant offset from pic_offset_table_rtx +
const(unspec(symbol_ref)+int_val) and pic_offset_table_rtx +
const(unspec(symbol_ref)), otherwise RTL may trap.
ISTM that rtx_addr_can_trap_p_1 is fundamentally broken in that
references via pic_offset_table_rtx can certainly trap.
Whether or not a given reference traps is a function of the size of
table (not known until link time) and the CONST_INT within the address
expression. So I'd be more inclined to remove the special casing of PIC
addresses where entirely -- that seemed pretty risky during stage3, but
now would be an appropriate time to tackle that.
If we were to try and keep the special handling, you certainly can't
depend on the form looking like (const(unspec(symbol_ref) + const_int).
You could have high/lo_sums were and probably other forms too. We allow
the backends to largely define what PIC address looks like.
Jeff
