llvm dev - Nov 2016 - 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

What about going for

template<unsigned N>
constexpr StringRef(const char (&Str)[N])

and avoiding strlen entirely for string literals?

-----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

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/20161125/675ee58b/attachment.html>

> On Nov 25, 2016, at 4:34 AM, Malcolm Parsons via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> 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
The only reason I didn’t go with this solution was that an MSVC built clang
would take a long time to startup if StringRef are present in global tables.

— 
Mehdi

> On 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?
We are allowing currently an explicit null char in the middle of a literal.

That’s why I had the constructor you mentioned but not using N for the length
here: https://reviews.llvm.org/D25639#497ba4c0

However this does not help with a construct like:


const char Arr[32];
fill(Arr);
StringRef S(Arr);

— 
Mehdi


> 
> -----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

On 25 November 2016 at 12:34, Malcolm Parsons <malcolm.parsons at
gmail.com> wrote:
> MSVC 2015 doesn't support C++14 extended constexpr. I don't know
how
> well it optimises a recursive strlen.
It's not as good at tail recursion optimisation as Clang, but it does
handle this:

constexpr size_t llvm_strlen(const char* s, size_t l = 0) {
  return *s ? llvm_strlen(s + 1, l + 1) : l;
}

Is stack usage in unoptimised builds an issue?

-- 
Malcolm Parsons