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

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-and-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.
-- 
Codeplay Software Ltd.
Company registered in England and Wales, number: 04567874
Registered office: Regent House, 316 Beulah Hill, London, SE19 3HF

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-and-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. :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200115/7f3c5871/attachment.html>

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