search for: constexprs

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

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:

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

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

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

The fact that the templatized constructor falls down because of the possibility of initializing StringRef with a stack-allocated char array kills that idea in my mind. I feel like the only two reasonable solutions are 1) allow UDL for this case, document that this is an exception and that UDLs are still not permitted anywhere else, and require (by policy, since I don't know of a way to have

On Mon, Nov 28, 2016 at 11:01 AM Mehdi Amini <mehdi.amini at apple.com> wrote: > On Nov 28, 2016, at 9:47 AM, David Blaikie via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > OK - 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

On 29 November 2016 at 17:38, Zachary Turner <zturner at google.com> wrote: > I see, but I looked 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 >

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 .cfi_offset %rbp, -16 movq

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

So, I split it up into three patches: - cflaa-danny-fixes.diff are (some of?) the fixes that Danny gave us earlier for tests + the minimal modifications 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

----- Original Message ----- > From: "George Burgess IV" <george.burgess.iv at gmail.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Chandler Carruth" <chandlerc at google.com>, "Jiangning Liu" <Jiangning.Liu at arm.com>, "LLVM Developers Mailing > List" <llvmdev at cs.uiuc.edu>, "Daniel

> I had thought that the case that Danny had looked at had a constant GEP, and so this constant might alias with other global pointers. How is that handled now? That issue had to do with that we assumed that for all arguments of a given Instruction, each argument was either an Argument, GlobalValue, or Inst in `for (auto& Bb : Inst.getBasicBlockList()) for (auto& Inst :

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 they can be one way, otherwise, you will unify

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

----- Original Message ----- > From: "George Burgess IV" <george.burgess.iv at gmail.com> > To: "Daniel Berlin" <dberlin at dberlin.org> > Cc: "Chandler Carruth" <chandlerc at google.com>, "Hal Finkel" <hfinkel at anl.gov>, "Jiangning Liu" > <Jiangning.Liu at arm.com>, "LLVM Developers Mailing

Sounds good, I'll reword that comment. Also, the assert you mentioned turned out to be a bad assumption when combined with how I foresee us handling inttoptr/ptrtoint in the future, so I'll just replace it with slightly more robust code. :) Thanks for the feedback, George On Tue, Feb 3, 2015 at 11:30 PM, Hal Finkel <hfinkel at anl.gov> wrote: > Hi George, > > +// Given an

On 1/20/2011 10:02 PM, Surinder wrote: > When I compile C programs into llvm, it produces load instructions in > two different flavours. > > (1) %8 = load i8** %bp, align 8 > > (2) %1 = load i8* getelementptr inbounds ([4 x i8]* @.str, i64 0, > i64 0), align 1 > > I know that %bp in first case and the entire "getelementptr inbounds > ([4 x i8]* @.str, i64

+1 to 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

Rui Ueyama via llvm-dev <llvm-dev at lists.llvm.org> writes: > - LLVM's `/*foo=*/`-style comment to annotate function arguments need > to be handled automatically to make the tool scalable. 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