search for: rvo

...th a simple ret instruction, so I’m surprised > not to see it for the version that doesn’t use move semantics. > > This a language ABI question. There's really nothing LLVM-specific about it. I would recommend thinking about it in terms of how to map C++ to C. As Davide pointed out, RVO is one reason to choose this particular lowering. These decisions are made inside Clang (not LLVM) and are mandated by the ABI (all compilers must implement them the same way for code to be able to be linked together and work). If you want all the gory details, the itanium C++ ABI is documented at...

...to think about, then IMO auto shouldn't be used as a coding style issue. > rvalue-refs | It is not very helpful when compiler can do return value optimization. I thought the motivation for adding rvalue-refs in C++11 was that in practice compilers can almost never do enough analysis to do RVO on real-world code? Regards, Dave -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purp...

...cts are cppm (https://github.com/istenith/cppm) CSC19 (https://github.com/istenith/CSC19) I believe the reasons I am a fit for this project are: - Ability to write generic code - Knowledge of internal workings of *C++*, *compilers*, and the *platforms(hardware concepts)* (ex.TMP, constexpr, RAII, RVO, cache lines, move semantics, undefined behaviors, thread-safety, etc.) *Which I came to know about, by closely following C++ communities and events such as cpplang.slack.com <http://cpplang.slack.com/>, CPPcon, core guidelines <https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines...

When trying to build the 11.0-CURRENT clang 3.5 on powerpc64 I ran into a violation of C++ accessibility rules (for private) that stopped the compile. So not the usual defect category. (This was a bootstrapping procedure as powerpc/powerpc64 FreeBSD world’s clang has an odd status and getting from 3.4 under 10.1-STABLE to 3.5 on 11.0-CURRENT is not automatic.) Given the language rules and

09.01.2013, 04:11, "Chris Lattner" <clattner at apple.com>: > It's seems like a quiet and peaceful day, lets stir things up a bit :) > > How crazy would it be for us to start using basic C++'11 language features (but not C++'11 library features) in LLVM: > things like auto It can make code less readable because of missing types. When compiler can deduce

...y.ll > llvm/trunk/test/CodeGen/AArch64/mergestores_noimplicitfloat.ll > llvm/trunk/test/CodeGen/AArch64/misched-stp.ll > llvm/trunk/test/CodeGen/AArch64/pr33172.ll > llvm/trunk/test/CodeGen/AArch64/tailcall-mem-intrinsics.ll > llvm/trunk/test/CodeGen/AArch64/tailcall-string-rvo.ll > llvm/trunk/test/CodeGen/AMDGPU/addrspacecast-constantexpr.ll > llvm/trunk/test/CodeGen/AMDGPU/lds-alignment.ll > llvm/trunk/test/CodeGen/AMDGPU/llvm.memcpy.ll > llvm/trunk/test/CodeGen/AMDGPU/lower-mem-intrinsics.ll > llvm/trunk/test/CodeGen/AMDGPU/promote-alloca-mem-i...

Hi all, I’m pretty new to the list, and to LLVM in general, so please excuse my extreme newbiesness. I’m trying to figure out what would be the appropriate way to implement move semantics. I’ve been trying to dump the IR produced by clang with some basic C++ snippet, but I’m afraid it didn’t help me much. Here’s the example I’ve been playing with (in C++): struct S { S() noexcept: x(new int)

...h64/merge-store-dependency.ll llvm/trunk/test/CodeGen/AArch64/mergestores_noimplicitfloat.ll llvm/trunk/test/CodeGen/AArch64/misched-stp.ll llvm/trunk/test/CodeGen/AArch64/pr33172.ll llvm/trunk/test/CodeGen/AArch64/tailcall-mem-intrinsics.ll llvm/trunk/test/CodeGen/AArch64/tailcall-string-rvo.ll llvm/trunk/test/CodeGen/AMDGPU/addrspacecast-constantexpr.ll llvm/trunk/test/CodeGen/AMDGPU/lds-alignment.ll llvm/trunk/test/CodeGen/AMDGPU/llvm.memcpy.ll llvm/trunk/test/CodeGen/AMDGPU/lower-mem-intrinsics.ll llvm/trunk/test/CodeGen/AMDGPU/promote-alloca-mem-intrinsics.ll llvm/trunk...

.../trunk/test/CodeGen/AArch64/mergestores_noimplicitfloat.ll >> llvm/trunk/test/CodeGen/AArch64/misched-stp.ll >> llvm/trunk/test/CodeGen/AArch64/pr33172.ll >> llvm/trunk/test/CodeGen/AArch64/tailcall-mem-intrinsics.ll >> llvm/trunk/test/CodeGen/AArch64/tailcall-string-rvo.ll >> llvm/trunk/test/CodeGen/AMDGPU/addrspacecast-constantexpr.ll >> llvm/trunk/test/CodeGen/AMDGPU/lds-alignment.ll >> llvm/trunk/test/CodeGen/AMDGPU/llvm.memcpy.ll >> llvm/trunk/test/CodeGen/AMDGPU/lower-mem-intrinsics.ll >> llvm/trunk/test/CodeGen/AMDGPU/...

...Gen/AArch64/mergestores_noimplicitfloat.ll >>> llvm/trunk/test/CodeGen/AArch64/misched-stp.ll >>> llvm/trunk/test/CodeGen/AArch64/pr33172.ll >>> llvm/trunk/test/CodeGen/AArch64/tailcall-mem-intrinsics.ll >>> llvm/trunk/test/CodeGen/AArch64/tailcall-string-rvo.ll >>> llvm/trunk/test/CodeGen/AMDGPU/addrspacecast-constantexpr.ll >>> llvm/trunk/test/CodeGen/AMDGPU/lds-alignment.ll >>> llvm/trunk/test/CodeGen/AMDGPU/llvm.memcpy.ll >>> llvm/trunk/test/CodeGen/AMDGPU/lower-mem-intrinsics.ll >>> llvm/trunk/...

...h64/merge-store-dependency.ll llvm/trunk/test/CodeGen/AArch64/mergestores_noimplicitfloat.ll llvm/trunk/test/CodeGen/AArch64/misched-stp.ll llvm/trunk/test/CodeGen/AArch64/pr33172.ll llvm/trunk/test/CodeGen/AArch64/tailcall-mem-intrinsics.ll llvm/trunk/test/CodeGen/AArch64/tailcall-string-rvo.ll llvm/trunk/test/CodeGen/AMDGPU/addrspacecast-constantexpr.ll llvm/trunk/test/CodeGen/AMDGPU/lds-alignment.ll llvm/trunk/test/CodeGen/AMDGPU/llvm.memcpy.ll llvm/trunk/test/CodeGen/AMDGPU/lower-mem-intrinsics.ll llvm/trunk/test/CodeGen/AMDGPU/promote-alloca-mem-intrinsics.ll llvm/trunk...

...h64/merge-store-dependency.ll llvm/trunk/test/CodeGen/AArch64/mergestores_noimplicitfloat.ll llvm/trunk/test/CodeGen/AArch64/misched-stp.ll llvm/trunk/test/CodeGen/AArch64/pr33172.ll llvm/trunk/test/CodeGen/AArch64/tailcall-mem-intrinsics.ll llvm/trunk/test/CodeGen/AArch64/tailcall-string-rvo.ll llvm/trunk/test/CodeGen/AMDGPU/addrspacecast-constantexpr.ll llvm/trunk/test/CodeGen/AMDGPU/lds-alignment.ll llvm/trunk/test/CodeGen/AMDGPU/llvm.memcpy.ll llvm/trunk/test/CodeGen/AMDGPU/lower-mem-intrinsics.ll llvm/trunk/test/CodeGen/AMDGPU/promote-alloca-mem-intrinsics.ll llvm/trunk...

I chatted with Chandler in person and came up with what I think is a much simpler design than my previous design in the thread titled "RFC: Introduce DW_OP_LLVM_memory to describe variables in memory with dbg.value". The crux of the problem in that thread is that we need a representation, particularly in the middle-end, to describe a variables address, at a particular program point.

...consistent. >> > > Inconsistent between what and what? LLVM and DWARF? Yeah, I guess there's > some mismatch between the semantics, though I'm still having trouble > wrapping my head around it. > I mean LLVM's model is internally inconsistent. We have bugs like the RVO one that you filed (https://llvm.org/pr34513), where we forget if the debug value is an address or a value. In LLVM IR today, the SSA value of the dbg.value *is* the interesting >> value, it is not the address, and we typically use empty DIExpressions. If >> the value is ultimately reg...

It's seems like a quiet and peaceful day, lets stir things up a bit :) How crazy would it be for us to start using basic C++'11 language features (but not C++'11 library features) in LLVM: things like auto, rvalue-refs, lambdas, etc? I think that we can keep things well defined with a few simple requirements: language features must be supported by MSVC 2010 and later, some version of

On Wed, Sep 6, 2017 at 10:01 AM, David Blaikie <dblaikie at gmail.com> wrote: > On Tue, Sep 5, 2017 at 1:00 PM Reid Kleckner via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> LLVM SSA values obviously do not have an address that we can take and >> they don’t live in registers, so neither the default memory location model >> nor DW_OP_regN make sense