This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: IVs optimization issue


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.

Thanks for your help,
Aurélien

> Richard.
> 
>>> Richard.
>>>
>>>> Thanks,
>>>> Aurélien
>>>>
>>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]