[llvm-dev] RFC: Constructing StringRefs at compile time

[David Blaikie via llvm-dev]

OK - good to know. (not sure we're talking about pessimizing it - just not
adding a new/possible optimization, to be clear)

Just out of curiosity - are there particular reasons you prefer or need to
ship an MSVC built version, rather than a bootstrapped Clang?

On Mon, Nov 28, 2016 at 9:24 AM Robinson, Paul <paul.robinson at sony.com>
wrote:

> So I wouldn't personally worry too much about performance degredation when
> built with MSVC - if, when building a stage 2 on Windows (building Clang
> with MSVC build Clang) you do end up with a compiler with the desired
> performance characteristics - then that's probably sufficient.
>
>
>
> Hold on there—we deliver an MSVC-built Clang to our licensees, and I would
> really rather not pessimize it.
>
> --paulr
>
>
>
> *From:* llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] *On Behalf Of *David
> Blaikie via llvm-dev
> *Sent:* Friday, November 25, 2016 8:52 AM
> *To:* Mueller-Roemer, Johannes Sebastian; Malcolm Parsons; Hal Finkel;
> llvm-dev at lists.llvm.org
>
>
> *Subject:* Re: [llvm-dev] RFC: Constructing StringRefs at compile time
>
>
>
>
>
> On Fri, Nov 25, 2016 at 6:10 AM Mueller-Roemer, Johannes Sebastian via
> llvm-dev <llvm-dev at lists.llvm.org> wrote:
>
> What about going for
>
> template<unsigned N>
> constexpr StringRef(const char (&Str)[N])
>
> and avoiding strlen entirely for string literals?
>
>
>
> You'd at least want an assert in there (that N - 1 == strlen(Str)) in case
> a StringRef is ever constructed from a non-const char buffer that's only
> partially filled.
>
> But if we can write this in such a way that it performs well on good
> implementations - that seems sufficient. If getting good performance out of
> the compiler means bootstrapping - that's pretty much the status quo
> already, as I understand it.
>
> So I wouldn't personally worry too much about performance degredation when
> built with MSVC - if, when building a stage 2 on Windows (building Clang
> with MSVC build Clang) you do end up with a compiler with the desired
> performance characteristics - then that's probably sufficient.
>
>
>
>
> -----Original Message-----
> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of
> Malcolm Parsons via llvm-dev
> Sent: Friday, November 25, 2016 13:34
> To: Hal Finkel <hfinkel at anl.gov>
> Cc: llvm-dev at lists.llvm.org
> Subject: Re: [llvm-dev] RFC: Constructing StringRefs at compile time
>
> On 24 November 2016 at 15:04, Hal Finkel <hfinkel at anl.gov> wrote:
> >> Creating constexpr StringRefs isn't trivial as strlen isn't portably
> >> constexpr and std::char_traits<char>::length is only constexpr in
> >> C++17.
> >
> > Why don't we just create our own traits class that has a constexpr
> length, and then we can switch over to the standard one when we switch to
> C++17?
>
> GCC and Clang treat __builtin_strlen as constexpr.
> MSVC 2015 doesn't support C++14 extended constexpr. I don't know how well
> it optimises a recursive strlen.
>
> This works as an optimisation for GCC and Clang, and doesn't make things
> worse for MSVC:
>
>      /// Construct a string ref from a cstring.
>      LLVM_ATTRIBUTE_ALWAYS_INLINE
> +#if __has_builtin(__builtin_strlen)
> +    /*implicit*/ constexpr StringRef(const char *Str)
> +        : Data(Str), Length(Str ? __builtin_strlen(Str) : 0) {} #else
>      /*implicit*/ StringRef(const char *Str)
>          : Data(Str), Length(Str ? ::strlen(Str) : 0) {}
> +#endif
>
> --
> Malcolm Parsons
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161128/8bf2a02a/attachment.html>