This is the mail archive of the 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

On Wed, Feb 29, 2012 at 4:41 PM, Aurelien Buhrig
<> wrote:
> Le 29/02/2012 16:15, Richard Guenther a écrit :
>> On Wed, Feb 29, 2012 at 4:08 PM, Aurelien Buhrig
>> <> 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)


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

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