llvm dev - Jan 2019 - Removing LLVM_ALWAYS_INLINE from ADT classes

On Thu, Jan 17, 2019 at 2:17 PM David Greene <dag at cray.com> wrote:
> Alex Bradbury via llvm-dev <llvm-dev at lists.llvm.org> writes:
>
> > As mentioned elsewhere in the thread, building TableGen with
> > Debug+Asserts isn't only useful for people who want to debug
TableGen
> > itself. It's useful for anybody modifying .td as many checks on
.td
> > input are only run in an asserts build. If there is a desire to move
> > to LLVM_OPTIMIZED_TABLEGEN by default I think the correct next step is
> > to write up a separate RFC on this, detailing the advantages,
> > disadvantages, and potential paths forward. One of the obvious path
> > forwards is to put development effort into ensuring that tablegen
> > doesn't need asserts enabled in order to catch invalid inputs.
>
> +1.  This is exactly the reason I'm nervous about making
> LLVM_OPTIMIZED_TABLEGEN on by default.  As someone who does a fair
> amount of .td twiddling and also occasionally hacks on TableGen itself,
> I almost never build it optimized.
>
Maybe LLVM_OPTIMIZED_TABLEGEN could do Release+Asserts builds?

(I don't have any opinion on anything here, just throwing out ideas)

>
>                            -David
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190117/b7e87476/attachment.html>

Nico Weber <thakis at chromium.org> writes:
>     +1. This is exactly the reason I'm nervous about making
>     LLVM_OPTIMIZED_TABLEGEN on by default. As someone who does a fair
>     amount of .td twiddling and also occasionally hacks on TableGen
>     itself, I almost never build it optimized.
>
> Maybe LLVM_OPTIMIZED_TABLEGEN could do Release+Asserts builds?
>
> (I don't have any opinion on anything here, just throwing out ideas)
When I'm hacking on TableGen, I frequently run it in a debugger and
anything that degrades that experience is problematic.  Ideally we'd
have better debugging experiences with optimized code but we're not
there yet.

TableGen should probably be reworked to not require asserts enabled to
detect bad input.  That just seems really wrong.  This would allow more
use of LLVM_OPTIMIZED_TABLEGEN but I personally would still want a debug
build to build a debug TableGen for use with a debugger.

                        -David

> -----Original Message-----
> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of
David
> Greene via llvm-dev
> Sent: Thursday, January 17, 2019 2:56 PM
> To: Nico Weber
> Cc: llvm-dev
> Subject: Re: [llvm-dev] Removing LLVM_ALWAYS_INLINE from ADT classes
> 
> Nico Weber <thakis at chromium.org> writes:
> 
> >     +1. This is exactly the reason I'm nervous about making
> >     LLVM_OPTIMIZED_TABLEGEN on by default. As someone who does a fair
> >     amount of .td twiddling and also occasionally hacks on TableGen
> >     itself, I almost never build it optimized.
> >
> > Maybe LLVM_OPTIMIZED_TABLEGEN could do Release+Asserts builds?
> >
> > (I don't have any opinion on anything here, just throwing out
ideas)
> 
> When I'm hacking on TableGen, I frequently run it in a debugger and
> anything that degrades that experience is problematic.  Ideally we'd
> have better debugging experiences with optimized code but we're not
> there yet.
> 
> TableGen should probably be reworked to not require asserts enabled to
> detect bad input.  That just seems really wrong.  This would allow more
> use of LLVM_OPTIMIZED_TABLEGEN but I personally would still want a debug
> build to build a debug TableGen for use with a debugger.
Personally I avoid TableGen like the plague, but its attitude towards
asserts does seem really wrong, and counter to how the rest of the project
works:  Asserts should verify internal consistency, and can be turned off
with a -Asserts build; bad user input should get a diagnostic, regardless
of the build mode.
--paulr
> 
>                         -David
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev