[llvm-dev] Removing LLVM_ALWAYS_INLINE from ADT classes (original) (raw)
Mehdi AMINI via llvm-dev llvm-dev at lists.llvm.org
Tue Jan 15 16:11:28 PST 2019
- Previous message: [llvm-dev] Removing LLVM_ALWAYS_INLINE from ADT classes
- Next message: [llvm-dev] Removing LLVM_ALWAYS_INLINE from ADT classes
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Tue, Jan 15, 2019 at 3:44 PM Davide Italiano <davide at freebsd.org> wrote:
On Mon, Jan 14, 2019 at 1:52 PM Reid Kleckner <rnk at google.com> wrote: > > On Fri, Jan 11, 2019 at 11:18 AM Davide Italiano via llvm-dev <_ _llvm-dev at lists.llvm.org> wrote: >> >> After yet another round of discussions, the plan is that of trying not >> to slap another attribute on the members, instead going for making >> OPTIMIZEDTLBGEN the default and removing alwaysinline. >> I'll do some testing locally (for the Ninja and the Xcode build >> generator). Pawel volunteered to take a look at the Visual Studio >> situation. >> I assume this is going to be the final plan we'll deploy unless >> somebody comes with any fundamental objections or there are technical >> hurdles down the road. > > > So, personally I feel strongly that LLVMOPTIMIZEDTABLEGEN should be off by default, since the it splits up the ninja build graph. We've also run into issues with it with VS: https://reviews.llvm.org/D54153 Shelling out to
cmake --build
as part of a build action doesn't seem to work very well for many generators. > > What actually blocks us from removing these alwaysinline attributes? When I read this thread, I didn't get the sense that debug build tablegen performance was actually important to anyone, but maybe I skimmed too much. >The only complain I heard was from somebody with a proprietary backend, but I contacted them again and they said it wasn't a problem for them anymore. You're right that nobody had fundamental objections to just drop the attributes.
I don't have anything against removing the attributes, but I'm curious about the "optimized builds" story (I hope it is OK to continue to hijack this thread for this?).
I wonder if there is a solution for having the ability to call these inline functions in an optimized build? Would modules solve this (with the right debugger support)?
The __attribute__(used)
could be used to produce "release" build with
"debug library support" (strawman wording), or better, without source
modification: a compiler flag could be used to automatically add the "used"
semantic to every inline function (and force emit all the inline function
for all class template instantiation, but that may be too costly).
I wonder if anyone thought about this?
-- Mehdi -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190115/505e6d17/attachment.html>
- Previous message: [llvm-dev] Removing LLVM_ALWAYS_INLINE from ADT classes
- Next message: [llvm-dev] Removing LLVM_ALWAYS_INLINE from ADT classes
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]