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.
BR,
Jiufu
Segher
