On 3/30/23 18:01, Hans-Peter Nilsson wrote:
On Fri, 24 Mar 2023, Peter Bergner via Gcc-patches wrote:
On 3/23/23 6:12 PM, Jeff Law via Gcc-patches wrote:
Is there a reason why REE cannot see that our (reg:QI 4) is a param register
and thus due to our ABI, already correctly sign/zero extended?
I don't think REE has ever considered exploiting ABI constraints. Handling
that might be a notable improvement on various targets. It'd be a great
place to do some experimentation.
Ok, so sounds like a good follow-on project after this patch is reviewed
and committed (stage1). Thanks for your input!
Agreed. I suspect that risc-v will benefit from such work as well.
With that in mind, if y'all start poking at this, please loop in Raphael
(on cc) who's expressed an interest in this space.
Will do. I suspect that it'll be best to come up with some generic interface
using target hooks like "param regs are sign/zero extended" or "call return
values are sign/zero extended", etc. that targets can conditionally opt into
depending on their ABI that is in effect.
Pardon the arm-chair development mode but it sounds like
re-inventing the TARGET_PROMOTE_* hooks...
Maybe just hook up TARGET_PROMOTE_FUNCTION_MODE to ree.c (as
"you" already already define it for "rs6000")?
That's what we touched on up-thread. Ideally we want to wire up REE to
utilize the existing mechanisms to specify ABI constraints so that we
don't have to write all those macros again.
jeff
