Ping.
On 2013/6/20 03:01 PM, Chung-Lin Tang wrote:
> Ping again?
>
> On 13/6/11 5:20 PM, Bernhard Reutner-Fischer wrote:
>> ping, CCing middle-end maintainers for review.
>>
>> On 31 May 2013 10:13, Chung-Lin Tang <clt...@codesourcery.com> wrote:
>>> On 13/5/15 8:12 PM, Richard Sandiford wrote:
>>>> Chung-Lin Tang <clt...@codesourcery.com> writes:
>>>>> On 13/5/10 6:37 PM, Richard Sandiford wrote:
>>>>>> Chung-Lin Tang <clt...@codesourcery.com> writes:
>>>>>>> + case UNSPEC:
>>>>>>> + /* Reach for a contained symbol. */
>>>>>>> + return nonzero_address_p (XVECEXP (x, 0, 0));
>>>>>>
>>>>>> I don't think this is safe. UNSPECs really are unspecified :-),
>>>>>> so we can't assume that (unspec X) is nonzero simply because X is.
>>>>>
>>>>> Attached is a modified patch (not yet tested but just for demonstration)
>>>>> with a more specific test, hopefully regarded as more safe.
>>>>>
>>>>> The point is in recognizing (const (unspec [symbol] XYZ)) offsets in PIC
>>>>> references, which seems quite idiomatic across all targets by now.
>>>>
>>>> I agree this is safer. However, there used to be some ports that
>>>> use (plus pic_offset_table_rtx (symbol_ref X)) -- i.e. without an unspec --
>>>> to represent a PIC reference to X. That always seemed semantically wrong,
>>>> since you're not actually adding the address of X and the PIC register,
>>>> but the patch wouldn't handle that case correctly.
>>>
>>> Well I can't help those targets then, but at least nothing will be
>>> changed for them by this patch. It will just continue to return 'true'.
>>>
>>>> An alternative might be to remove the pic_offset_table_rtx case altogether
>>>> and rely on targetm.delegitimize_address instead. FWIW, I'd prefer that
>>>> if it works, but it's not me you need to convince. :-)
>>>
>>> Like we discussed below, I think the direction should be towards making
>>> things more machine-independent, rather then pushing more into the backend.
>>>
>>>>> I would suggest that this probably means there should be a new, more
>>>>> specific construct in RTL to represent relocation values of this kind,
>>>>> instead of (const (unspec)) serving an unofficial role; possibly some
>>>>> real support for reasoning about PIC references could also be considered.
>>>>
>>>> Yeah, maybe we could try to introduce some target-independent knowledge
>>>> of certain reloc types, a bit like the generic BFD_RELOC_*s in bfd.
>>>
>>>
>>> FWIW, I've ran tests on the newer patch on i686-linux, with no
>>> regressions. Testcase has been moved to gcc.dg/torture by recommendation
>>> of Bernhard. If any of the RTL maintainers can give an eye of merciful
>>> approval, this old PR could be resolved :)
>>>
>>> Thanks,
>>> Chung-Lin
>>>
>
