Hi Jakub, on 2024/4/2 16:03, Jakub Jelinek wrote: > On Tue, Apr 02, 2024 at 02:12:04PM +0800, Kewen.Lin wrote: >>>>>> The old code for the unused hidden parameter (which was the 9th param) >>>>>> would >>>>>> fall thru to the "return NULL_RTX;" which would make the callee assume >>>>>> there >>>>>> was a parameter save area allocated. Now instead, we'll return a reg >>>>>> rtx, >>>>>> probably of r11 (r3 thru r10 are our param regs) and I'm guessing we'll >>>>>> now >>>>>> see a copy of r11 into a pseudo like we do for the other param regs. >>>>>> Is that a problem? Given it's an unused parameter, it'll probably get >>>>>> deleted >>>>>> as dead code, but could it cause any issues? What if we have more than >>>>>> one >> >> I think Peter raised one good point, not sure it would really cause some >> issues, >> but the assigned reg goes beyond GP_ARG_MAX_REG, at least it is confusing to >> people >> especially without DCE like at -O0. Can we aggressively remove these >> candidates >> from DECL_ARGUMENTS chain? Does it cause any assertion to fail? > > I'd prefer not to remove DECL_ARGUMENTS chains, they are valid arguments that > just some > invalid code doesn't pass. By removing them you basically always create an > invalid case, this time in the other direction, valid caller passes more > arguments than the callee (invalidly) expects.
Thanks for the comments, do you mean it can affect the arguments validation when there is explicit function declaration with interface? Then can we strip them when we are going to expand them (like checking currently_expanding_function_start)? since from the perspective of resulted assembly, with this workaround, the callee can: 1) pass the hidden args in unexpected GPR like r11, ... at -O0; 2) get rid of such hidden args as they are unused at -O2; This proposal aims to make the assembly at -O0 not to pass with r11... (same as -O2), comparing to the assembly at O2, the mismatch isn't actually changed. BR, Kewen
