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

[Robinson, Paul 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)

Okay, glad to hear it.  I admit I wasn't following the thread all that closely.

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

We experiment with a bootstrapped Clang from time to time.  The benefit has never been clearly worth the additional cost of internally supporting a Windows-target Clang.  (Which is non-trivial; yes it's still Clang, but it's a different target OS, different object-file format, different debug-info format, etc.)
--paulr

From: David Blaikie [mailto:dblaikie at gmail.com]
Sent: Monday, November 28, 2016 9:47 AM
To: Robinson, Paul; Mueller-Roemer, Johannes Sebastian; Malcolm Parsons; Hal Finkel
Cc: llvm-dev at lists.llvm.org
Subject: Re: [llvm-dev] RFC: Constructing StringRefs at compile time

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<mailto: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<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<mailto: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<mailto: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<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<mailto:hfinkel at anl.gov>>
Cc: llvm-dev at lists.llvm.org<mailto: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<mailto: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<mailto: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<mailto: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/9f8c27e6/attachment-0001.html>