https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61078
--- Comment #6 from jgreenhalgh at gcc dot gnu.org --- > Also there seem to be other code (gimplify.c) which still depends on > PUSH_ARGS_REVERSED?! Indeed. I left that out of mercy to those users (erroneously) relying on the order of evaluating function arguments. C and C++ explicitly mark the evaluation order as unspecified, but there seems no good reason to break user expectations. If we were to revert my patch, we would have to either remove the tie between what gimple thinks of as PUSH_ARGS_REVERSED and what expand thinks of as PUSH_ARGS_REVERSED, or break (admittedly broken and not-portable) user code. > I'm also not sure about the performance impact of this. On S/390 the generated > code changes a lot with your patch. As mentioned in the original patch submission [1], the effect is to allow removal the removal of temporary registers when shuffling arguments for a call. I can't speak to the performance on S/390. Certainly if your arguments are predominantly stack-based I wouldn't expect to see any benefit, but I wouldn't expect to see much harm either, assuming and reading and writing to descending stack locations was as efficient as reading and writing to ascending stack locations. That assumption might well not hold for S/390. If S/390 passes small numbers of arguments in registers, I'd expect the net result to be positive for performance. [1]: https://gcc.gnu.org/ml/gcc-patches/2014-03/msg01252.html
