[llvm-dev] [tablegen] table readability / performance
Reid Kleckner via llvm-dev
llvm-dev at lists.llvm.org
Wed Jan 15 13:28:11 PST 2020
It would. In this case, we would need to add CMake logic to pass the option
when running tablegen. I'm not sure how to detect this precise case, though.
On Wed, Jan 15, 2020 at 12:16 PM Martin Storsjö <martin at martin.st> wrote:
> 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:
> > >
> > 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
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev