From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1633 invoked by alias); 28 Aug 2014 16:00:25 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 1235 invoked by uid 48); 28 Aug 2014 16:00:19 -0000 From: "jgreenhalgh at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug bootstrap/61078] [5 Regression] ESA mode bootstrap failure since r209897 Date: Thu, 28 Aug 2014 16:00:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: bootstrap X-Bugzilla-Version: 5.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: jgreenhalgh at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 5.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-08/txt/msg01915.txt.bz2 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