David Blaikie via llvm-dev
2016-Nov-25 16:51 UTC
[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/20161125/675ee58b/attachment.html>
Robinson, Paul via llvm-dev
2016-Nov-28 17:24 UTC
[llvm-dev] RFC: Constructing StringRefs at compile time
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<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/c88c9d98/attachment-0001.html>
David Blaikie via llvm-dev
2016-Nov-28 17:47 UTC
[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> 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>