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

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

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

Hi Reid, Martin

On Wed Jan 15, 2020 at 9:28 PM, Reid Kleckner wrote:
> 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.
>
Okay. I think I managed a reasonable middle-ground. By default, if
cross-compiling or running cmake with Visual Studio, emit char literal
arrays, otherwise string literals. The user can override at runtime with
a switch.

I've pushed a patch to phab: https://reviews.llvm.org/D73044

Please tag any extra reviewers who may be interested.

Thanks for the input.

All the Best

Luke

-- 
Codeplay Software Ltd.
Company registered in England and Wales, number: 04567874
Registered office: Regent House, 316 Beulah Hill, London, SE19 3HF