[llvm-dev] Disabling LLVM_ATTRIBUTE_ALWAYS_INLINE for development? (original) (raw)

Kristina Brooks via llvm-dev llvm-dev at lists.llvm.org
Sat Dec 15 12:16:16 PST 2018

My understanding of always_inline is that the attribute is meant to be used where not inlining a function would cause a (incorrect) change in semantics of the function (anything that uses certain builtins or inline assembly getting values of certain common registers like FP/SP/PC). Could it be worth adding another macro for the attribute that is less ambiguous in terms of whether forced inlining is a case of optimization, to distinguish it from uses (I'm not actually sure if there are any) where it may actually inadvertently change semantics?

On Sat, Dec 15, 2018 at 8:02 PM Vedant Kumar via llvm-dev < llvm-dev at lists.llvm.org> wrote:

Hi,

> On Dec 15, 2018, at 10:32 AM, Brian Gesiak via llvm-dev <_ _llvm-dev at lists.llvm.org> wrote: > > Hello all! > > I find that using lldb to debug LLVM libraries can be super > frustrating, because a lot of LLVM classes, like the constructor for > StringRef, are marked LLVMATTRIBUTEALWAYSINLINE. So when I attempt > to have lldb evaluate an expression that implicitly instantiates a > StringRef, I get 'error: Couldn't lookup symbols: _> ZN4llvm9StringRefC1EPKc'. > > As an example, most recently this happened to me when playing around > with llvm::AttributeSet, having attached lldb to an opt built with > -DCMAKEBUILDTYPE="Debug": > > (lldb) e $AS.hasAttribute("myattr") > error: Couldn't lookup symbols: _> ZN4llvm9StringRefC1EPKc > > Despite having built in a "Debug" configuration, > LLVMATTRIBUTEALWAYSINLINE makes it very difficult to debug LLVM. > > How do you all deal with or work around this problem? I don't think there are any great workarounds. The data formatters in utils/lldbDataFormatters.py can help a bit.

> Is there a good > way to do so? If not, would anyone object if I sent up a patch to > introduce a CMake variable or something to conditionally disable > LLVMATTRIBUTEALWAYSINLINE? I'd like to be able to turn it off, but > I'm not sure if there's some good reason it needs to stay on even for > debug builds? IIRC the motivation for using alwaysinline in debug builds was to make binaries acceptably fast. IMHO this isn't the right tradeoff because it also makes binaries frustratingly hard to debug. Some might object that with clang modules, it should be no trouble for a debugger to evaluate these kinds of expressions. I've CC'd Raphael who can speak to this much better than I can. My understanding is that modules may help, but lldb (and presumably gdb as well?) are not going to learn how to parse templated code out of C++ modules, instantiate them, and JIT-compile them for you really soon. That seems like an ongoing, longer-term project. I'd like to see us move away from using alwaysinline in core ADT headers to make debugging easier in the near future. A note about slow Debug binaries. In my experience it's really never necessary have a separate Debug build tree. It takes up a slot of time/space and I've never found it useful. It's usually much more convenient to have a single RelAsserts build tree. If you need to debug code in some .cpp file, you can just: $ touch path/to/the/file.cpp $ export CCCOVERRIDEOPTIONS="+-g O0 +-UNDEBUG" $ ninja opt/clang/etc The build system will do an incremental recompile of the binary you want to debug, with the single file (or set of files) you care about recompiled with asserts, at -O0, with debug info. The resulting binary is pretty much just as fast as a RelAsserts binary and is perfectly debuggable, modulo alwaysinline functions ;) vedant > > - Brian Gesiak _> ________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

LLVM Developers mailing list llvm-dev at lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181215/7c9d5e55/attachment.html>

More information about the llvm-dev mailing list