From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 3C7383858C00; Sat, 17 Jun 2023 08:25:07 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3C7383858C00 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1686990308; bh=h/mycQ6qs9fKs6SJjZV1/2rCdHxJogxPfJeap6x5a4M=; h=From:To:Subject:Date:In-Reply-To:References:From; b=DAEh+I3ACTrpPnKhMsOd8o3ehgg0Wecc7Ei8g6SyMLUk7rcFawojoLgVLh4xYTiGO XEDd4zUJT7rZxLhA/eT19vm3aSWCgdkQRVgOnSlL2l1FbbSnRpX0FHEYTJgweRD45j ULzA8a7jt74X/0GDySrx3lPAEH04z/9p5odZq6SY= From: "klepikov.alex+bugs at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/54089] [SH] Refactor shift patterns Date: Sat, 17 Jun 2023 08:24:59 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 4.8.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: klepikov.alex+bugs at gmail dot com X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: olegendo at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D54089 --- Comment #79 from Alexander Klepikov --- (In reply to Oleg Endo from comment #78) > (In reply to Alexander Klepikov from comment #77) > > > It'd be good if the newly added passes are ran only with -O2 or highe= r. > >=20 > > This can be confusing to users when they discover that not all invarian= ts > > are moved out of loops. Then we should inform them about that at least. >=20 > I don't think the compiler reports any optimizations not done to the user= at > lower optimization levels? It's normal not to do certain optimizations a= t a > lower level, that's why we have -O0 -O1 -O2 ... or do you mean something > else by that? >=20 I mean that if a user run GCC with -O1 and we don't do SH specific loop move invariants pass at -O1, a user could look at binary (or at .S file) and find that not all invariants are moved out of the loops, because library address= es are hoisted after split1 pass. That would confuse a user even if RTL dump is generated, and he can decide that it's a bug into loop2 pass. I suggest to generate sh_loop dumps if RTL dump is requested and place there a message t= hat sh_loop hoisting is not done due to optimization level setting. But, actually, it's not that important at the moment because I'm aiming to = do the second option - run sh_loop only when it's potentially needed. > The compiler processes one function at a time, all passes at once. That's what I missed! Thank you for clarification! > > I see some strange new exec fails only at testsuite logs. Right now I'm > > trying to find the cause. >=20 > What's the configure line of your GCC build? ../gcc-13.1.0/configure --target=3Dsh-elf --with-endian=3Dbig,little --disable-bootstrap --enable-languages=3Dc,c++ --disable-nls --with-gnu-as --with-gnu-ld --prefix=3D/usr/local/sh-toolchain/ --without-newlib --without-headers I checked several cases and they are because ld cannot link little endian binary. When I run failed command taken from log file, it always fails for linking little endian binary. But sometimes logs say that executing of litt= le endian binary is successful. I'm at a loss - how is that even possible?=