[llvm-dev] [tablegen] table readability / performance

Martin Storsjö via llvm-dev llvm-dev at lists.llvm.org
Wed Jan 15 12:16:05 PST 2020


On Wed, 15 Jan 2020, Reid Kleckner via llvm-dev wrote:

> On Wed, Jan 15, 2020 at 11:14 AM Luke Drummond <luke.drummond at codeplay.com>
> wrote:
>       On Wed Jan 15, 2020 at 6:58 PM, Reid Kleckner wrote:
>       > Does the same limitation exist in VS 2017? I think that's our
>       support
>       > floor
>       > these days:
>       >https://llvm.org/docs/GettingStarted.html#host-c-toolchain-both-compiler-an
>       d-standard-library
>       >
>       It appears that all releases including the latest 2019 are
>       affected.
>       >
>       > One *could* make the tablegen behavior conditional on the
>       compiler, and
>       > generate the character arrays for VS, and strings for other
>       compilers.
>       > It
>       > has the potential to create MSVC only issues, but it seems
>       harmless
>       > enough...
>       I can't see any current `#ifdef _MSCV_VER` usage in tablegen but
>       I'm happy to
>       besmirch it for this.
> 
> 
> I think the cleanest way to do this would be to have a cl::opt to control
> how string tables are emitted, and then control the default with `#if
> defined(_MSC_VER) && !defined(__clang__)`. The !clang check is so I get the
> benefits of this locally with clang-cl. :)

Would this assume that the compiler compiling tablegen would be the same 
as compiling the generated code? I do occasionally cross compile from 
linux with MSVC, and in those cases, the tablegen is built as a native 
linux binary.

// Martin



More information about the llvm-dev mailing list