Le 01/03/2012 11:09, Richard Guenther a écrit : > On Wed, Feb 29, 2012 at 6:02 PM, Aurelien Buhrig > <aurelien.buhrig....@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....@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....@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 >>>>>> >>>> >>