On Thu, 11 May 2023 07:21:30 PDT (-0700), jeffreya...@gmail.com wrote:
On 5/11/23 04:33, Robin Dapp wrote:
"csr_operand" does seem wrong, though, as that just accepts constants.
Maybe "arith_operand" is the way to go? I haven't looked at the
V immediates though.
I was pondering changing the shift-count operand to QImode everywhere
but that indeed does not help code generation across the board. It can
still work but might require extra patterns here and there.
Yea. It's a GCC wart and there hasn't ever been a clear best direction
on the mode for the shift count. If you use QImode, as you note you
often end up having to add various patterns to avoid useless conversions
and such.
Yes, and I think given that we have so much weirdness for the sub-XLEN
types in the RISC-V port we'd need to have a lot of fairly large
patterns and some truncation-based fallbacks. We've got some of those
for the integer shifts already, though, so maybe it's the way to go?
FWIW, I was trying to suggest X or REG as the shift amount and thought
we'd done it that way for the integer shifts too. I think we can
reason about that with just some tiny code snippits, even if it's not
the right way to go long term (as per below). Probably a minor win,
though, and I don't think it needs to block the patches.
Also: looks like I was wrong and "csr_operand" does the correct thing
here because there's only a 5-bit immediate for the shift amounts. We
should probably name it something else, though, as this has nothing to
do with CSRs...
I suspect QImode isn't ideal on a target like RV where we don't really
have QImode operations. So all we do is force the introduction of
subregs all over the place to force the operand in to QImode. It's
something I'd like to explore, but would obviously require a fair amount
of benchmarking to be able to confidently say which is better.
Folks have tried a few times and it's never ended up better. I do think
we're at a local minimum here, though -- ie, explicitly handling the
shorter types would result in better generated code if we got everything
right. Gut feeling is that'd require a meaningful amount of middle-end
work, though, as we're sufficiently different than MIPS here (and
arm64/x86 have many of the ops).
Nobody in Rivos land is looking at this right now, though it's a pretty
common red flag for new people and frequently trips up code gen so that
might change with little notice...
Jeff
