[llvm-dev] Removing LLVM_ALWAYS_INLINE from ADT classes
Nico Weber via llvm-dev
llvm-dev at lists.llvm.org
Mon Jan 14 15:11:14 PST 2019
I agree that shelling out to `cmake --build` as a build step is pretty ugly.
It seems kind of simpler to me to just always build Support and TableGen
with O3 always, even in debug builds. Most people don't debug code in
Support and TableGen, and there could be a disable switch for those that
do. That gives you a fast(er) debug build without building any files twice.
Is that something CMake can do? If so, is this something that was
(It's not implemented, but in the GN build it's in theory doable to have a
release toolchain and always use that for tablegen, that way you have the
same effect, but the duplicate build of tablegen is just part of the
regular build. But I figured the "always O3 for lib/Support and
lib/TableGen" approach would be nicer there too. Since I always do Release
builds like Reid and just switch to Debug when I need it, it wasn't a
priority for me to think too much about this though.)
On Mon, Jan 14, 2019 at 4: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
>> OPTIMIZED_TLBGEN the default and removing always_inline.
>> I'll do some testing locally (for the Ninja and the Xcode build
>> generator). Pawel volunteered to take a look at the Visual Studio
>> 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 LLVM_OPTIMIZED_TABLEGEN 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 always_inline 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.
> Maybe I am a luddite because I just build Release+Asserts with debug info
> enabled and then sprinkle `#pragma clang optimize off` around when I need
> to debug a particular source file. This keeps build & test fast enough
> except in the corner cases where a debugger is required.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev