On Fri, 9 Jul 2021, Segher Boessenkool wrote: > On Fri, Jul 09, 2021 at 08:43:59AM +0200, Richard Biener wrote: > > I wonder if there's a way to query the target what modes the doloop > > pattern can handle (not being too familiar with the doloop code). > > You can look what modes are allowed for operand 0 of doloop_end, > perhaps? Although that is a define_expand, not a define_insn, so it is > hard to introspect. > > > Why do you need to do any checks besides the new type being able to > > represent all IV values? The original doloop IV will never wrap > > (OTOH if niter is U*_MAX then we compute niter + 1 which will become > > zero ... I suppose the doloop might still do the correct thing here > > but it also still will with a IV with larger type). > > doloop_valid_p guarantees it is simple and doesn't wrap. > > > I'd have expected sth like > > > > ntype = lang_hooks.types.type_for_mode (word_mode, TYPE_UNSIGNED > > (ntype)); > > > > thus the decision made using a mode - which is also why I wonder > > if there's a way to query the target for this. As you say, > > it _may_ be fast, so better check (somehow). > > 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. s390x for example seems to handle both SImode and DImode (but names the helper gen_doloop_si64 for SImode?!). 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. Richard.
