[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