On 04/28/17 18:48, Jeff Law wrote: > 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. >
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. Bernd.
