This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: IVs optimization issue
- From: Aurelien Buhrig <aurelien dot buhrig dot gcc at gmail dot com>
- To: Richard Guenther <richard dot guenther at gmail dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Thu, 01 Mar 2012 14:42:43 +0100
- Subject: Re: IVs optimization issue
- Authentication-results: mr.google.com; spf=pass (google.com: domain of aurelien.buhrig.gcc@gmail.com designates 10.204.130.204 as permitted sender) smtp.mail=aurelien.buhrig.gcc@gmail.com; dkim=pass header.i=aurelien.buhrig.gcc@gmail.com
- References: <4F4DDDBB.6070903@gmail.com> <CAFiYyc3p5=vaKvJfeq2j1f9SNJGJkLhd92ShUwuadFT1YGUmmw@mail.gmail.com> <4F4E3F7B.5080900@gmail.com> <CAFiYyc3VXSH6bUDaE+3J4FeiP02rMreAPKx_n976hDRMDv-48g@mail.gmail.com> <4F4E4734.1000504@gmail.com> <CAFiYyc0HEYapH0Y61gfbciO=Ni98GvWcxcNhJkpP53w42eTZLA@mail.gmail.com> <4F4E5A2D.4060609@gmail.com> <CAFiYyc0U7w6S00bEBPCDH17WRSTfxZttZOKck8gkygwshpyE4w@mail.gmail.com>
Le 01/03/2012 11:09, Richard Guenther a écrit :
> 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.
It's what I meant.Thank you for your reply,
Aurélien
> Richard.
>
>> Thanks for your help,
>> Aurélien
>>
>>> Richard.
>>>
>>>>> Richard.
>>>>>
>>>>>> Thanks,
>>>>>> Aurélien
>>>>>>
>>>>
>>