Hi, Jeff Law <jeffreya...@gmail.com> writes:
> 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. Right. > > It may be overkill, but you might consider making it a PARAM that can > be adjusted. Yes. I also feel the magic number is not perfect. I'm thinking of a way to mark if a param is stored to stack from the register when setup, and then reference the marker during this optimization. This would be more accurate and able to avoid the magic number. > > >> >> 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. Right! Thanks a lot for your comments! BR, Jeff (Jiufu) > > jeff
