Disable debug-info generation with a top-level attribute

[p0nce]

SIMD headers have hundreds, if not thousands of functions, so clang uses __nodebug__ attribute to avoid for a particular function.
I've not found a way to do it in LDC.

Because we have no raw text macros, what I would want is to disable debug generation of all functions defined at top-level, with a:

pragma(disableDebugInfo, true):
(or something similar at top-level)

This is because there are so much functions it would be impractical to copy/paste for each.

[JohanEngelen]

(if something like this is implemented, I will sneakily use it to look at IR without debug annotations on godbolt.org :P)

[kinke]

I will sneakily use it to look at IR without debug annotations

Is -g enforced there?

[I don't see this as good first issue, there are myriads of more important things IMO. This to me just sounds like a feature request due to the build system not being able to accomodate for some files to be compiled with specific flags (no -g) or Guillaume not wanting to compile the whole lib without debuginfos. It'd be somewhere at the very bottom of my priorities list.]

[p0nce]

To be very specific, I'm trying to make something a bit like the <emmintrin.h>header, in clang C++ it has the macro:

#define __DEFAULT_FN_ATTRS __attribute__((__always_inline__, __nodebug__, __target__("sse2"), __min_vector_width__(128)))

I feel like:

• inlining is best left to the compiler and maybe shouldn't be there,
• feature enabling is best left to the library user and shouldn't be there,
• "min vector width" is not a concern yet https://clang.llvm.org/docs/AttributeReference.html#min-vector-width

So that leaves __nodebug__ which is by far not an absolute need. But, as I would imagine, such __nodebug__ are possibly there to lead to faster builds. This is definately a feature request.

(And yes, also with DUB you can't make --combined build AND have package-specific, let alone file-specific flags. But --combined seems to be needed to get cross-inlining here with LDC... hence why -g doesn't cut it)

[kinke]

hence why -g doesn't cut it

With LTO it does (edit: ah, you're going for compilation speed). If going for best speed, there's just no avoiding LTO, incl. LTO druntime/Phobos. We do have an experimental cross module inliner though.

So are you shipping optimized builds with debuginfos (and at the same time want to save a bit of build-time by excluding the debuginfos for a specific module)?

[p0nce]

I was just thinking of: "compilation speed of debug builds, done with LDC" indeed, maybe such a flag would help. I also wonder why it's that way in clang. If there is something that would help more, good as well :)

[kinke]

For C++, that header is included (not imported ;)) in each referencing .cpp, so I guess the number of overall functions (and hence debuginfos) multiplies badly, so that something like __nodebug__ does pay off.

[JohanEngelen]

I don't see this as good first issue, there are myriads of more important things IMO

What you find important is completely irrelevant for what makes a good first issue. It's simple to implement, that's what makes it a good first issue.

[p0nce]

We have a "little-RoI" tag for these kind of issues who don't create much value.