Jiong Wang writes:
> Andrew Pinski writes:
>
>> On Tue, Jul 28, 2015 at 6:12 AM, Jiong Wang <jiong.w...@arm.com> wrote:
>>>
>>> The instruction sequences for preparing argument for TLS descriptor
>>> runtime resolver and the later function call to resolver can actually be
>>> hoisted out of the loop.
>>>
>>> Currently we can't because we have exposed the hard register X0 as
>>> destination of "set". While GCC's RTL data flow infrastructure will
>>> skip or do very conservative assumption when hard register involved in
>>> and thus some loop IV opportunities are missed.
>>>
>>> This patch add another "tlsdesc_small_pseudo_<mode>" pattern, and avoid
>>> expose x0 to gcc generic code.
>>>
>>> Generally, we define a new register class FIXED_R0 which only contains
>>> register
>>> 0, so the instruction sequences generated from the new add pattern is the
>>> same
>>> as tlsdesc_small_<mode>, while the operand 0 is wrapped as pseudo register
>>> that
>>> RTL IV opt can handle it.
>>>
>>> Ideally, we should allow operand 0 to be any pseudo register, but then
>>> we can't model the override of x0 caused by the function call which is
>>> hidded by the UNSPEC.
>>>
>>> So here, we restricting operand 0 to be x0, the override of x0 can be
>>> reflected to the gcc.
>>>
>>> OK for trunk?
>>
>>
>> This patch broke ILP32 because we used mode rather than ptr_mode for
>> the psedu . I have an idea on how to fix it (like tlsie_small_sidi
>> case) but I still need to test it fully.
>
> Have done a quick re-visit the code, the use of "mode" instead of
> "ptr_mode" looks OK to me.
>
> While what looks strange to me is under ILP32 symbol_ref is DImode.
>
> (symbol_ref:DI ("*.LANCHOR0")
>
> My my understanding, the symbol_ref should be SI mode under ilp32
> instead of DI mode.
>
> So it's better to fix "create_block_symbol" in varasm, and we should let
> it use ptr_mode instead of Pmode as Pmode is used to describe the
> underline hardware mode instead of the mode view in C language level.
meanwhile I revert this patch (r228211) as there is unresolved ILP32
issue.
--
Regards,
Jiong
