Displaying 14 results from an estimated 14 matches for "llvm_attribute_always_inlin".
Did you mean:
llvm_attribute_always_inline
2015 Dec 21
2
MSVC warning noise on "LLVM_ATTRIBUTE_ALWAYS_INLINE inline void foo()"
On Mon, Dec 21, 2015 at 12:08 AM, Aaron Ballman <aaron at aaronballman.com>
wrote:
> On Sun, Dec 20, 2015 at 5:57 PM, Johan Engelen <jbc.engelen at gmail.com>
> wrote:
> >
> > Perhaps LLVM_ATTRIBUTE_ALWAYS_INLINE could be defined to "inline" if the
> > compiler has no support for always_inline (currently it is set to
> nothing in
> > that case) ?
> > I think this would allow removal of the "inline" after
> > LLVM_ATTRIBUTE_ALWAYS_INLINE.
>
> Wouldn't...
2015 Dec 20
2
MSVC warning noise on "LLVM_ATTRIBUTE_ALWAYS_INLINE inline void foo()"
Hi all,
Some functions have "inline" specified twice by use of
LLVM_ATTRIBUTE_ALWAYS_INLINE.
For example in StringRef.h:
LLVM_ATTRIBUTE_ALWAYS_INLINE
inline bool operator==(StringRef LHS, StringRef RHS);
This results in warning noise when compiled with MSVC 2015:
\include\llvm/ADT/StringRef.h(567): warning C4141: 'inline': used more
than once
\include\llvm/ADT/StringRef....
2015 Dec 20
2
MSVC warning noise on "LLVM_ATTRIBUTE_ALWAYS_INLINE inline void foo()"
On Sun, Dec 20, 2015 at 5:24 PM, Xinliang David Li via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> LLVM_ATTRIBUTE_ALWAYS_INLINE is defined to be __forceinline for MSVC. I
> wonder why you get that warning.
inline and __forceinline don't mix with MSVC -- I believe they may be
modeled with the same attribute under the hood. I'm not certain of the
best way to solve this aside from suggesting to ignore C4141 locall...
2018 Dec 15
4
Disabling LLVM_ATTRIBUTE_ALWAYS_INLINE for development?
Hello all!
I find that using lldb to debug LLVM libraries can be super
frustrating, because a lot of LLVM classes, like the constructor for
StringRef, are marked LLVM_ATTRIBUTE_ALWAYS_INLINE. So when I attempt
to have lldb evaluate an expression that implicitly instantiates a
StringRef, I get 'error: Couldn't lookup symbols:
__ZN4llvm9StringRefC1EPKc'.
As an example, most recently this happened to me when playing around
with llvm::AttributeSet, having attached lldb to an...
2018 Dec 16
3
Disabling LLVM_ATTRIBUTE_ALWAYS_INLINE for development?
...10:32 AM, Brian Gesiak via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> >
> > Hello all!
> >
> > I find that using lldb to debug LLVM libraries can be super
> > frustrating, because a lot of LLVM classes, like the constructor for
> > StringRef, are marked LLVM_ATTRIBUTE_ALWAYS_INLINE. So when I attempt
> > to have lldb evaluate an expression that implicitly instantiates a
> > StringRef, I get 'error: Couldn't lookup symbols:
> > __ZN4llvm9StringRefC1EPKc'.
> >
> > As an example, most recently this happened to me when playing around
>...
2018 Dec 17
2
Disabling LLVM_ATTRIBUTE_ALWAYS_INLINE for development?
...sts.llvm.org> wrote:
>> > >
>> > > Hello all!
>> > >
>> > > I find that using lldb to debug LLVM libraries can be super
>> > > frustrating, because a lot of LLVM classes, like the constructor for
>> > > StringRef, are marked LLVM_ATTRIBUTE_ALWAYS_INLINE. So when I attempt
>> > > to have lldb evaluate an expression that implicitly instantiates a
>> > > StringRef, I get 'error: Couldn't lookup symbols:
>> > > __ZN4llvm9StringRefC1EPKc'.
>> > >
>> > > As an example, most recentl...
2016 Nov 25
5
RFC: Constructing StringRefs at compile time
...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
2016 Nov 25
2
RFC: Constructing StringRefs at compile time
...gt; 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) {}
> +#e...
2016 Nov 28
5
RFC: Constructing StringRefs at compile time
...gt; 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) {}
> +#e...
2016 Nov 28
3
RFC: Constructing StringRefs at compile time
...gt; 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) {}
> +#e...
2016 Nov 28
3
RFC: Constructing StringRefs at compile time
...gt; 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) {}
> +#e...
2016 Nov 29
2
RFC: Constructing StringRefs at compile time
On 29 November 2016 at 16:18, Zachary Turner <zturner at google.com> wrote:
> I don't like the llvm_strlen approach as it is incompatible with
> std::string_view which we may eventually move to.
In what way is it incompatible?
constexpr StringRef(const char* s) : Data(s), Length(llvm_strlen(s)) {}
is equivalent to
constexpr string_view(const char* s) : Data(s),
2016 Nov 24
3
RFC: Constructing StringRefs at compile time
Hi all,
There is a desire to be able to create constexpr StringRefs to avoid
static initializers for global tables of/containing StringRefs.
Creating constexpr StringRefs isn't trivial as strlen isn't portably
constexpr and std::char_traits<char>::length is only constexpr in
C++17.
Alp Toker tried to create constexpr StringRefs for strings literals by
subclassing StringRef:
2016 Sep 25
8
Is it time to allow StringRef to be constructed from nullptr?
While porting LLDB over to StringRef, I am continuously running into
difficulties caused by the fact that StringRef cannot be constructed from
nullptr. So I wanted to see peoples' thoughts on removing this restriction
from StringRef. To be clear, I'm only using LLDB as a motivating example,
but I'm not requesting that it be done because LLDB is some kind of special
case. If it is to