On 11/28/22 20:53, Jiufu Guo wrote:
Right, but the number of registers is target dependent, so I don't see
how using "8" or any number of that matter is correct here.
I understand. And even for the same struct type, using how many
registers to pass a parameter, it also dependends on the size of the
parameter and how many leading parameters there is.
So, as you said, "8" or any numbers are not always accurate.
Because, the enhancement in this patch is just make "block move" to be
more friendly for follow optiomizations(cse/dse/dce...) by moving
through sub-mode. So, I just selected one arbitrary number which may
not too large and also tolerable.
I also through to query the max number registers from targets for
param/ret passing, but it may not very accurate neither.
Any sugguestions are welcome! and thanks!
OK, so it's just a magic number and (in theory) any number should still
generate correct code -- the number merely places limits on when we'll
consider performing this optimization.
It may be overkill, but you might consider making it a PARAM that can be
adjusted.
For this patch, only simple stuffs are handled like "D.xxx = param_1",
where the source and dest of the assignment are all in memory which is
the DECL_RTL(of D.xx/param_xx) in MEM_P/BLK.
And to avoid complicate, this patch only handle the case where
"(size % mode_size) == 0".
If any misunderstandings, please point out, thanks.
And thanks for comments!
How values are justified varies on the PA depending on whether the
parameter is passed in registers or in memory. Though thinking more
about things, I don't think you're changing how the parameter is passed.
Just how it's subsequently pulled out of memory.
jeff
