For now, for 64 bit SVR4 ABI, when lowering a CALL, a byval parameter bigger than 8 bytes will be copied to the caller's stack frame. This will cause some issues because when the byval parameter is smaller than 64 bytes (assume there is only one parameter). HasParameterArea is not set to true, so on the caller side, the stack local area overlaps with the parameter save area.
In D105271, I tried to set the HasParameterArea to true even the byval parameter can be entirely passed in registers. That patch can fix the above overlap issue.
But with the fix D105271, we met a new issue when mix-compiling with other compilers like GCC:
On the callee side,
If the callee is compiled with clang and the parameter is set to be with byval parameter in some IR generator, (assume there is only one parameter for the callee and the parameter size is bigger than 8 bytes but smaller than 64 bytes), then the callee assumes the caller will allocate parameter save area, so the callee will store the parameter passed by register to caller's parameter save area.
On the caller side,
If the caller is also compiled with clang, then we are OK as it will use the new logic I added in D105271. Caller and callee have a consistent parameter save area allocation policy.
But if the caller is compiled with other compilers, like GCC, then we will meet some issues. Because GCC will not allocate parameter save area for structures smaller than 64 bytes (assume there is only one parameter).
So I reverted D105271 and propose this new fix.
Now we won't copy the byval parameter (bigger than 8 bytes) to caller's parameter save area. Instead, we will only copy the byval parameter when it can not be passed entirely in registers which means we have to use parameter save area according to the 64 bit SVR4 ABI.