On Wed, Jul 14, 2021 at 5:11 AM guojiufu via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: > > On 2021-07-13 23:38, Segher Boessenkool wrote: > > On Mon, Jul 12, 2021 at 08:20:14AM +0200, Richard Biener wrote: > >> On Fri, 9 Jul 2021, Segher Boessenkool wrote: > >> > Almost all targets just use Pmode, but there is no such guarantee I > >> > think, and esp. some targets that do not have machine insns for this > >> > (but want to generate different code for this anyway) can do pretty much > >> > anything. > >> > > >> > Maybe using just Pmode here is good enough though? > >> > >> I think Pmode is a particularly bad choice and I'd prefer word_mode > >> if we go for any hardcoded mode. > > > > In many important cases you use a pointer as iteration variable. > > > > Is word_mode register size on most current targets? > Had a search on the implementation, word_mode is the mode on size > BITS_PER_WORD > in MODE_INTs. Actually, when targets define Pmode and BITS_PER_WORD, > these two > macros are aligned -:), and it seems most targets define both these two > macros. > > > > >> s390x for example seems to handle > >> both SImode and DImode (but names the helper gen_doloop_si64 > >> for SImode?!). > > > > Yes, so Pmode will work fine for 390. It would be nice if we could > > allow multiple modes here, certainly. Can we? > > :), for other IVs, multiple modes are allowed to add as candidates; > while only one doloop iv is added. Comparing the supporting more > doloop IVs, it seems changing the doloop iv mode is easy relatively > for me. So, the patch is trying to update doloop iv. > > > > >> But indeed it looks like somehow querying doloop_end > >> is going to be difficult since the expander doesn't have any mode, > >> so we'd have to actually try emit RTL here. > > > > Or add a well-designed target macro for this. "Which modes do we like > > for IVs", perhaps? > > In the new patch, a target hook preferred_doloop_mode is introduced. > While > this hook is only for doloop iv at this time. > Maybe we could have preferred_iv_mode if needed. In the current code, > IVs > are free to be added in different types, and the cost model is applied > to determine which IV may be better. The iv mode would be one factor for > cost.
I guess IVOPTs could directly look at PROMOTE_MODE & friends to decide whether the IV increment has extra cost due to subregs/extensions and account for that. The rest should be really driven by the cost to express IV uses, I don't think putting another target hook in here will help reduce GIGO. Richard. > > BR, > Jiufu > > > > > > > Segher
