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? > Richard. > >> Thanks, >> Aurélien >>
