Re: IVs optimization issue

[Richard Guenther <richard dot guenther at gmail dot com>]

On Wed, Feb 29, 2012 at 6:02 PM, Aurelien Buhrig
<aurelien.buhrig.gcc@gmail.com> wrote:
> Le 29/02/2012 17:08, Richard Guenther a écrit :
>> On Wed, Feb 29, 2012 at 4:41 PM, Aurelien Buhrig
>> <aurelien.buhrig.gcc@gmail.com> wrote:
>>> Le 29/02/2012 16:15, Richard Guenther a écrit :
>>>> On Wed, Feb 29, 2012 at 4:08 PM, Aurelien Buhrig
>>>> <aurelien.buhrig.gcc@gmail.com> wrote:
>>>>>
>>>>>> The issue is most probably that on GIMPLE we only deal with ptr_mode,
>>>>>> not Pmode, and IVOPTs thinks that pointer induction variables will
>>>>>> have ptr_mode. ?To fix this the cost computation would need to take
>>>>>> into account ptr_mode to Pmode conversions _and_ would need to
>>>>>> consider Pmode IVs in the first place (I'm not sure that will be easy).
>>>>>
>>>>>
>>>>> Thank you Richard for you reply.
>>>>>
>>>>> I guess such an issue is not in the top priority tasks of main
>>>>> developers. So I think I'll have to look at it myself if I feel
>>>>> confident enough to carry out such a job (I've never worked at tree level).
>>>>>
>>>>> My main wonder is about Pmode IVs: since GIMPLE representation only
>>>>> deals with ptr_mode, what differentiates a Pmode IV from a ptr_mode one?
>>>>
>>>> Its TREE_TYPE. ?In your case you'd have a POINTER_TYPE with
>>>> PSImode for Pmode and a POINTER_TYPE with SImode for ptr_mode
>>>> pointers. ?They will differ in TYPE_MODE and TYPE_PRECISION.
>>>
>>> Thanks, I will look at it.
>>>
>>>>> BTW, this wonder is not limited to IVs. What does control the choice of
>>>>> Pmode vs ptr_mode when mapping to RTL?
>>>>
>>>> ptr_mode is the C language specified mode for all pointers. ?Pmode is
>>>> the mode used for pointers in address operands of CPU instructions.
>>>> Usually they are the same. ?When mapping to RTL all ptr_mode uses
>>>> for memory accesses are translated to Pmode while operations on
>>>> the value of ptr_mode quantities are done on ptr_mode (IIRC).
>>>
>>> Another point that is not optimal for my backend is when computing the
>>> address of an array element (M[i]). Now, both the M address and i are
>>> extended to ptr_mode and the sum is truncated in Pmode; whereas it would
>>> be much better to extend i to Pmode, and then perform the add in Pmode.
>>> So if I understand correctly, the later option cannot be generated. Right?
>>
>> Not by IVOPTs at least. ?There is also the long-standing issue that
>> POINTER_PLUS_EXPR only accepts sizetype offsets - that may cause
>> issues if your target does not define sizetype having the same mode as
>> ptr_mode. ?(And of course complicates using Pmode on the gimple level)
>
> Sorry, it wasn't related to ivopts, but on the use of Pmode from Gimple,
> and especially when computing a M[i] address. (My ptr_mode and SIZE_TYPE
> mode are the same). Can you confirm that it's not possible to compute
> the address of M[i] in Pmode without truncating from ptr_mode? Because
> mapping POINTER_PLUS_EXPR directly to Pmode would also be (with ivopts
> PSI support) a great improvement for Pmode=PSImode targets.

Not sure what you mean with "not possible", it's not done.

Richard.

> Thanks for your help,
> Aurélien
>
>> Richard.
>>
>>>> Richard.
>>>>
>>>>> Thanks,
>>>>> Aurélien
>>>>>
>>>
>