From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 39631385742B; Fri, 29 Apr 2022 19:07:16 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 39631385742B From: "tromey at sourceware dot org" To: gdb-prs@sourceware.org Subject: [Bug gdb/29104] GDB very slow running LLVM opt Date: Fri, 29 Apr 2022 19:07:16 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: gdb X-Bugzilla-Version: 11.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: tromey at sourceware dot org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot 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://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gdb-prs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-prs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2022 19:07:16 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D29104 --- Comment #3 from Tom Tromey --- (In reply to Martin Sebor from comment #2) > Like this? (The 25 second delay is after the Command execution time: line > is printed and before the rest of the output.) Normally it's better not to pass the file name on the command line, and use "file", in case it's symbol reading that is slow. Anyway here that doesn't seem to be an issue. I guess you mean the first time that is printed? > (gdb) r -S -instcombine x.ll > 2022-04-29 12:10:34.658 - command started > Starting program: /ssd/build/llvm-gcc/bin/opt -S -instcombine x.ll > 2022-04-29 12:10:34.737 - command finished > Command execution time: 0.070464 (cpu), 0.078909 (wall) ^^^ right here. I forgot that "run" doesn't really DTRT with "maint time 1". There's a bug about this somewhere. Last time I had a problem like this it was due to a bad interaction between "gcc -g3" and an lld/mold linker problem. If that isn't your issue then there's no better approach than profiling to see if the problem can be discovered. It's possible there's just a very large CU and expanding it is slow, though 25 seconds seems a bit beyond. Another possibility is expanding too many CUs. "set debug dwarf-read 1" might uncover this. --=20 You are receiving this mail because: You are on the CC list for the bug.=