llvm dev - Jan 2019 - Removing LLVM_ALWAYS_INLINE from ADT classes

On Mon, 14 Jan 2019 at 23:11, Nico Weber via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> 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 considered?
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.

Best,

Alex

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.

                           -David

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>