Ping...
On 05/12/17 18:48, Bernd Edlinger wrote:
> Ping...
>
> On 04/29/17 09:06, 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.
>>>
>>
>> Yes, I like this idea.
>>
>> I tried to compile openssl with -m32 -fpic as an example, and counted
>> how often the mem[pic+const] is hit: that was 2353 times, all kind of
>> object refs.
>>
>> Then I tried your idea, and only 54 unhandled pic refs remained, all of
>> them looking like this:
>>
>> (plus:SI (reg:SI 107)
>> (const:SI (plus:SI (unspec:SI [
>> (symbol_ref:SI ("bf_init") [flags 0x2] <var_decl
>> 0x2ac00f7bac60 bf_init>)
>> ] UNSPEC_GOTOFF)
>> (const_int 4164 [0x1044]))))
>>
>> I believe that is a negligible fall out from such a big code base.
>>
>> Although the pic references do no longer reach the
>> SYMBOL_REF_FUNCTION_P in this version of the patch, I still see
>> that happening without -fpic option, so I left it as is.
>>
>>
>> Attached is the new version of my patch.
>>
>> Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
>> Is it OK for trunk?
>>
>>
>> Thanks
>> Bernd.
