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