From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26369 invoked by alias); 17 Apr 2005 00:22:23 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 26211 invoked by alias); 17 Apr 2005 00:22:02 -0000 Date: Sun, 17 Apr 2005 00:22:00 -0000 Message-ID: <20050417002202.26210.qmail@sourceware.org> From: "roger at eyesopen dot com" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20050221214433.20126.jkohen@users.sourceforge.net> References: <20050221214433.20126.jkohen@users.sourceforge.net> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug target/20126] [3.3/3.4/4.0 Regression] Inlined memcmp makes one argument null on entry X-Bugzilla-Reason: CC X-SW-Source: 2005-04/txt/msg02231.txt.bz2 List-Id: ------- Additional Comments From roger at eyesopen dot com 2005-04-17 00:21 ------- Subject: Re: [PR target/20126, RFC] loop DEST_ADDR biv replacement may fail Hi Alex, On 16 Apr 2005, Alexandre Oliva wrote: > On Apr 15, 2005, Roger Sayle wrote: > > I agree with your proposed game plan of keeping the hard failure in > > place temporarily, to discover whether there are any other "fallback" > > strategies that would be useful. Ultimately though, I don't think we > > should close PR20126 until a "soft failure" is implemented on mainline, > > like we've (Jakub has) done on the gcc-4_0-branch (such as the > > mainline code proposed in comment #30). > > But see, the problem with the soft failure mode is that, if it is ever > legitimate to leave the giv alone and not make sure we set whatever > register appears in it to the right value, then can't we always do it, > removing all of the (thus useless) workarounds? > > And if there's any case in which it is not legitimate to do so, then > the soft failure mode would be a disservice to the user, that would > silently get a miscompiled program. We should probably at least warn > in this case. I don't believe there are any cases in which it is not legitimate to leave the GIV alone, so we'll never silently miscompile anything. My understanding is that it's always possible to leave the giv alone (provided that we set all_reduced to false). The "workarounds" as we've got used to calling them are not required for correctness, but for aggressive optimization. There's clearly a benefit to strength reducing GIVs, and the harder we try to replace them, the better the code we generate. Yes, they are (useless/not necessary) from a purely correctness point of view; we don't even have to call validate_change we could just always give-up and punt using clearing all_reduced (technicaly we don't have to perform any loop optimizations for correctness), but we'd generate pretty poor code. The patch you proposed provides the soft failure mode we want (and now have on the release branch). We could, as you say remove all of the current workarounds, and the only thing that would suffer is the quality of the code we generate. Needless to say, I'd prefer to keep these optimizations (for example your recent one for Josh to allow us to strength reduce the ARM's stim instruction). It's not unreasonable to try three or four approaches before giving up, and forcing the optimizers to preserve the original GIV. Does this clear things up? Do you agree? Roger -- -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20126