[Bug c++/28935] GDB very slow stepping through LLVM compiled by Clang

["simark at simark dot ca" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=28935

--- Comment #3 from Simon Marchi <simark at simark dot ca> ---
(In reply to Martin Sebor from comment #2)
> In both of my sessions GDB stops on the same lines and shows the same output
> (I pasted the output below just in case I'm overlooking something).  But
> with more testing I think the problem might be more involved than I thought.
> I reproduces in GDB in Emacs (and also in VSCode) but it's not nearly as
> pronounced with GDB invoked in the terminal (there's a still a delay there
> but much shorter).
> 
> If you're willing to try to reproduce it with LLVM (and ideally with Emacs)
> that would be great.
> 
> I use stock GCC and LLVM (and Emacs) on Fedora 35 to build LLVM:
> 
>   gcc version 11.2.1 20211203 (Red Hat 11.2.1-7) (GCC)
>   clang version 13.0.0 (Fedora 13.0.0-3.fc35)
> 
> I invoke CMake to configure LLVM for Clang and Ninja either in
> /build/llvm-clang or /build/llvm-gcc, respectively, like so:
> 
>   $ CC=clang CXX=clang++ cmake -G Ninja /src/llvm/llvm -DLLVM_USE_LINKER=lld
> -DLLVM_ENABLE_PROJECTS="llvm"
> 
> (or without CC and CXX to use the stock GCC), and the use Ninja to build:
> 
>   $ ninja -C /build/llvm-clang -j16 -l12 -v
> or
>   $ ninja -C /build/llvm-gcc -j16 -l12 -v
> 
> While LLVM is building, create an a.ll file from the C program shown below:
> 
>   $ cat a.c && clang -O1 -S -emit-llvm -Xclang -disable-llvm-passes -o a.ll
> a.c
>   void f (void *p, void *q)
>   {
>     __builtin_memcpy (p, q, 4);
>   }
>
> Once LLVM is finished building, start a GDB session (either on the command
> line, or better, in Emacs, with M-x gdb) with opt as the executable, set a
> breakpoint in llvm::MemCpyOptPass::processMemCpy, and run the opt executable
> with the options as shown and the a.ll file as an operand:
> 
>   $ gdb -nx /build/llvm-clang/bin/opt
>   (gdb) break llvm::MemCpyOptPass::processMemCpy
>   (gdb) run -S -basic-aa -memcpyopt a.ll
>   Breakpoint 1, llvm::MemCpyOptPass::processMemCpy (this=0x994ba28,
> M=0x994c2c0, BBI=...) at
> /src/llvm/llvm/lib/Transforms/Scalar/MemCpyOptimizer.cpp:1375
>   1375	  if (M->isVolatile()) return false;
>   (gdb) step
>   llvm::MemIntrinsic::isVolatile (this=0x994c2c0) at
> /src/llvm/llvm/include/llvm/IR/IntrinsicInst.h:953
>   953	  bool isVolatile() const { return !getVolatileCst()->isZero(); }
> 
> (Your line numbers will be different than mine.)  The step command and other
> next or step commands in this context take about a second to complete in GDB
> started in a terminal.  That's long but actually tolerable.  It takes about
> 3 seconds when I start the same GDB session in Emacs (or in VSCode).  When I
> follow the same steps with LLVM compiled with GCC the step and next commands
> complete pretty much instantaneously, both in GDB started in a terminal or
> (with a slight delay) in Emacs.  In other contexts (like in main()), step
> and next complete without a delay either way.

Ok, I tried to follow this as best as I could, but I can't see a noticeable
difference between both, unfortunately.  I tested on Ubuntu 20.04 (but also gcc
11, from the Ubuntu toolchain PPA, and clang 13, from the LLVM apt repo).

I didn't test with emacs, as I have no idea how to use it.

-- 
You are receiving this mail because:
You are on the CC list for the bug.