search for: constexpr's

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

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

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), Length(std::char_traits<char>::length(s)) {} -- Malcolm Parsons

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

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

...- good to know. (not sure we're talking about pessimizing it - just not > adding a new/possible optimization, to be clear) > > > This does not seem that clear to me. The motivation seems to be able to > create global table of StringRef, which we don’t do because the lack fo > constexpr of static initializers right now. > Moving forward it would mean making clang a lot slower when built with > MSVC if we were going this route. > > > Ah, fair - perhaps I misunderstood/misrepresented, apologies. Figured this > was just an attempt to reduce global initializers in ar...

...- good to know. (not sure we're talking about pessimizing it - just not > adding a new/possible optimization, to be clear) > > > This does not seem that clear to me. The motivation seems to be able to > create global table of StringRef, which we don’t do because the lack fo > constexpr of static initializers right now. > Moving forward it would mean making clang a lot slower when built with > MSVC if we were going this route. > Ah, fair - perhaps I misunderstood/misrepresented, apologies. Figured this was just an attempt to reduce global initializers in arrays we alread...

...ooked over your proposed implementation from earlier in the > thread, and if I'm not mistaken I see this: That's a different suggestion. > That said, what did you think about my other proposal of the complicated UDL > with macro? > > #define LIT(x) x_string_ref_literal > constexpr StringRef Strings[] = {LIT("a"), LIT("b"), LIT("c")}; Why bother with the UDL? #define LIT(x) StringRef((x), sizeof(x)-1) -- Malcolm Parsons

Hi Devs, consider below testcase $cat test.cpp constexpr int product() { return 10*20; } int main() { const int x = product(); return 0; } $./clang test.cpp -std=c++11 -S $./clang -v clang version 9.0.0 Target: x86_64-unknown-linux-gnu $cat test.s main: .cfi_startproc # %bb.0: pushq %rbp .cfi_def_cfa_offset 16...

On 28 November 2016 at 20:51, Zachary Turner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > The basic idea here is that you introduce a StringLiteral class and anywhere > you want to use a global constructor, you make sure to declare a constexpr > array instead of a normal array, and you make it of type StringLiteral. I prefer constexpr llvm_strlen() over StringLiteral because it doesn't require code changes outside StringRef - all StringRefs constructed from a literal can benefit. But there are concerns about MSVC. I prefer Strin...

...ions you’d need to make in CFLAA to make them pass tests. - cflaa-minor-bugfixes.diff consists primarily of a bug fix for Argument handling — we’d always report NoAlias when one of the given variables was an entirely unused argument (We never added the appropriate Argument StratifiedAttr) - cflaa-constexpr-fix.diff - The fix for the constexpr behavior we’ve been seeing Patches are meant to be applied in the order listed. Also, I just wanted to thank everyone again for your help so far — it’s greatly appreciated. :) George > On Jan 30, 2015, at 11:56 AM, Hal Finkel <hfinkel at anl.gov> wr...

...; it is test fixes, another bit is a minor bug fix, etc. > > Yes, please break it into independent parts. > > > > > > > Important bit (WRT ConstantExpr): moved the loop body from > > buildGraphFrom into a new function. The body has a few tweaks to > > call constexprToEdges on all ConstantExprs that we encounter. > > constexprToEdges, naturally, interprets a ConstantExpr (and all > > nested ConstantExprs) and places the results into a > > SmallVector<Edge>. > > > > > > I'm assuming this method of handling Constant...

...> it is test fixes, another bit is a minor bug fix, etc. > > Yes, please break it into independent parts. > > > > > > > Important bit (WRT ConstantExpr): moved the loop body from > > buildGraphFrom into a new function. The body has a few tweaks to > > call constexprToEdges on all ConstantExprs that we encounter. > > constexprToEdges, naturally, interprets a ConstantExpr (and all > > nested ConstantExprs) and places the results into a > > SmallVector<Edge>. > > > > > > I'm assuming this method of handling ConstantEx...

George, given that, can you just build constexpr handling (it's not as easy as you think) as a separate funciton and have it use it in the right places? FWIW, my current list of CFLAA issues is: 1. Unknown values (results from ptrtoint, incoming pointers, etc) are not treated as unknown. These should be done through graph edge (so that the...

On Mon, Mar 3, 2014 at 12:26 AM, Chris Lattner <sabre at nondot.org> wrote: > > On Mar 2, 2014, at 8:53 PM, Renato Golin <renato.golin at linaro.org> wrote: > > > On 3 March 2014 12:32, Pete Cooper <peter_cooper at apple.com> wrote: > >> Would those work with a foreach construct? Perhaps I forgot to mention > that was what I'm trying to work out

...le bits later today, because some of > it is test fixes, another bit is a minor bug fix, etc. Yes, please break it into independent parts. > > > Important bit (WRT ConstantExpr): moved the loop body from > buildGraphFrom into a new function. The body has a few tweaks to > call constexprToEdges on all ConstantExprs that we encounter. > constexprToEdges, naturally, interprets a ConstantExpr (and all > nested ConstantExprs) and places the results into a > SmallVector<Edge>. > > > I'm assuming this method of handling ConstantExprs isn't 100% correct &...

...ss tests. > > - cflaa-minor-bugfixes.diff consists primarily of a bug fix for > > Argument handling — we’d always report NoAlias when one of the given > > variables was an entirely unused argument > > (We never added the appropriate Argument StratifiedAttr) > > - cflaa-constexpr-fix.diff - The fix for the constexpr behavior we’ve > > been seeing > > > > > > Patches are meant to be applied in the order listed. > > > > > > Also, I just wanted to thank everyone again for your help so far — > > it’s greatly appreciated. :) > &...

...> How can I find out when I am in Instruction object I and I.getOpcode() > == 29 whether I am dealing with type (1) or type (2) above. The second load instruction is not really a "special" load instruction. Rather, its pointer argument is an LLVM constant expression (class llvm::ConstExpr). The Getelementptr (GEP), which would normally be a GEP instruction, is instead a constant expression that will be converted into a constant numeric value at code generation time. So, what you need to do is to examine the LoadInst's operand and see if its a ConstExpr, and then see whether...

...o C++14. On Thu, May 10, 2018 at 10:37 PM, Nathan Froyd via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Firefox's experience is that GCC 5 isn't going to cut it, especially > if you move to MSVC 2017, because people are going to be quickly > annoyed at the lack of relaxed constexpr function support, which is > GCC 6+. Are you sure? I think you meant GCC 4.9 isn't going to cut it, ... ... annoyed at the lack of relaxed constexpr function support, which is GCC 5. https://gcc.gnu.org/projects/cxx-status.html. Relaxing requirements on constexpr functionsN36525__cpp_const...

...le. So is the > doxygen @parameter. This is a bit of a side note, but in my own work I've more recently tried to move from this style: foo.h int foo(int a, bool doSomething); foo.cpp x = foo(a, /*doSomething=*/true); y = foo(a, /*doSomething=*/false); to something like: foo.h inline constexpr DoDoSomething = true; inline constexpr DontDoSomething = false; int foo(int a, bool doSomething); foo.cpp x = foo(a, DoDoSomething); y = foo(a, DontDoSomething); One doesn't need the inline variable (and thus not C++17) if one uses macros or enums or something else less elegant. This kin...