Alexander Shaposhnikov via llvm-dev
2020-Sep-28 19:46 UTC
[llvm-dev] preferred way to return expected values
Many thanks for the reply, right, this is what the discussion is about. On Mon, Sep 28, 2020 at 10:57 AM David Blaikie <dblaikie at gmail.com> wrote:> To clarify, this is a discussion around whether given some move-only type > X, implicitly convertible to Y and the code "Y func() { X x; return x; }" > is that valid in LLVM? (and, as a corollary, if the type isn't move-only, > is that code efficient (does it move rather than copying) - as in the > vector example given) > > I /believe/ the answer is that it is not valid. I think the set of > compilers supported includes those that do not implement this rule. (either > due to the language version we compile with, or due to it being a DR that > some supported compiler versions do not implement). But that's just my > rough guess. > > On Sat, Sep 26, 2020 at 3:17 PM Alexander Shaposhnikov via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hello everyone! >> It looks like in the LLVM codebase (including subprojects) there are some >> inconsistencies >> in how values are returned from functions with the following (or similar) >> signature: >> Expected<std::vector<int>> createVector() { >> std::vector<int> V; >> ... >> } >> It would be interesting to find out your opinion on this. >> After some investigation I have found https://reviews.llvm.org/D70963 >> and https://reviews.llvm.org/D43322 which have some additional context >> regarding >> the problem. The aforementioned diffs (and the comments on them) contain >> a lot of >> details and the history of the problem (whether one should use the cast >> or not). >> If I am not mistaken a part of the problem is that compilers' behaviors >> have changed over time, and e.g. the latest versions would use a move >> constructor while the older ones could use a copy constructor. So the >> question is where we stand at the moment / what is the recommended approach >> for the new code. >> >> Many thanks in advance, >> Alexander Shaposhnikov >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> https://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/20200928/0ddd5007/attachment.html>
George Rimar via llvm-dev
2020-Oct-01 09:08 UTC
[llvm-dev] [EXTERNAL] Re: preferred way to return expected values
FWIW, I've performed an experiment with the code below at godbolt. (used -O2, https://godbolt.org/z/nY95nh) ``` #include <vector> #include "llvm/Support/Error.h" llvm::Expected<std::vector<int>> foo() { std::vector<int> V; V.push_back(0); return V; } ``` If I understand the produced output correctly, then results are: gcc 7.5: creates a copy. gcc 8.1: uses move. clang < 6.0: doesn't compile. clang >= 6.0: uses move. MSVS: was unable to compile, complains about "llvm/Support/Error.h" header. I am using MSVS 2017 locally and it calls move constructor of Expected<> though, so I think all MSVS >= 2017 (at least) should be fine.? Best regards, George | Developer | Access Softek, Inc ________________________________ От: Alexander Shaposhnikov <alexander.v.shaposhnikov at gmail.com> Отправлено: 28 сентября 2020 г. 22:46 Кому: David Blaikie Копия: Richard Smith; llvm-dev; Lang Hames; George Rimar; James Henderson; avl.lapshin at gmail.com Тема: [EXTERNAL] Re: [llvm-dev] preferred way to return expected values CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. If you suspect potential phishing or spam email, report it to ReportSpam at accesssoftek.com Many thanks for the reply, right, this is what the discussion is about. On Mon, Sep 28, 2020 at 10:57 AM David Blaikie <dblaikie at gmail.com<mailto:dblaikie at gmail.com>> wrote: To clarify, this is a discussion around whether given some move-only type X, implicitly convertible to Y and the code "Y func() { X x; return x; }" is that valid in LLVM? (and, as a corollary, if the type isn't move-only, is that code efficient (does it move rather than copying) - as in the vector example given) I /believe/ the answer is that it is not valid. I think the set of compilers supported includes those that do not implement this rule. (either due to the language version we compile with, or due to it being a DR that some supported compiler versions do not implement). But that's just my rough guess. On Sat, Sep 26, 2020 at 3:17 PM Alexander Shaposhnikov via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: Hello everyone! It looks like in the LLVM codebase (including subprojects) there are some inconsistencies in how values are returned from functions with the following (or similar) signature: Expected<std::vector<int>> createVector() { std::vector<int> V; ... } It would be interesting to find out your opinion on this. After some investigation I have found https://reviews.llvm.org/D70963 and https://reviews.llvm.org/D43322 which have some additional context regarding the problem. The aforementioned diffs (and the comments on them) contain a lot of details and the history of the problem (whether one should use the cast or not). If I am not mistaken a part of the problem is that compilers' behaviors have changed over time, and e.g. the latest versions would use a move constructor while the older ones could use a copy constructor. So the question is where we stand at the moment / what is the recommended approach for the new code. Many thanks in advance, Alexander Shaposhnikov _______________________________________________ LLVM Developers mailing list llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org> https://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/20201001/c2804292/attachment.html>
David Blaikie via llvm-dev
2020-Oct-01 19:00 UTC
[llvm-dev] [EXTERNAL] Re: preferred way to return expected values
On Thu, Oct 1, 2020 at 2:08 AM George Rimar <grimar at accesssoftek.com> wrote:> FWIW, I've performed an experiment with the code below at godbolt. > (used -O2, https://godbolt.org/z/nY95nh) > > ``` > #include <vector> > #include "llvm/Support/Error.h" > > llvm::Expected<std::vector<int>> foo() { > std::vector<int> V; > V.push_back(0); > return V; > } > ``` >I think the easiest and portable way to test this functionality would be more like: #include <memory> struct base { virtual ~base(); }; struct derived : base { }; std::unique_ptr<base> f() { std::unique_ptr<derived> d; return d; } That shows whether the compiler's treating the return of a temporary as movable, even when the types aren't an exact match. Clang 3.5 does not support this conversion: https://godbolt.org/z/5nsWM8 GCC 5.1 does support it: https://godbolt.org/z/cvd3d6 & I'm not sure which MSVC version on godbolt would be "MSVC 2017" that the LLVM docs refer to.> > If I understand the produced output correctly, then results are: > > gcc 7.5: creates a copy. > gcc 8.1: uses move. > > clang < 6.0: doesn't compile. >That's interesting - I wonder if LLVM's documentation is out of date, which claims the minimum required Clang is 3.5: https://llvm.org/docs/GettingStarted.html#host-c-toolchain-both-compiler-and-standard-library> clang >= 6.0: uses move. > > MSVS: was unable to compile, complains about "llvm/Support/Error.h" header. > I am using MSVS 2017 locally and it calls move constructor of Expected<> > though, > so I think all MSVS >= 2017 (at least) should be fine. >May be something to do with which compiler the llvm library provided by godbolt is compiled with? which might make the above results not quite right (& why testing with the non-llvm-specific example might be clearer) Looks like we would need to bump the minimum Clang up from 3.5 to at least 3.9 to allow returns with implicit moves that include conversions. - Dave> > > Best regards, > George | Developer | Access Softek, Inc > ------------------------------ > *От:* Alexander Shaposhnikov <alexander.v.shaposhnikov at gmail.com> > *Отправлено:* 28 сентября 2020 г. 22:46 > *Кому:* David Blaikie > *Копия:* Richard Smith; llvm-dev; Lang Hames; George Rimar; James > Henderson; avl.lapshin at gmail.com > *Тема:* [EXTERNAL] Re: [llvm-dev] preferred way to return expected values > > CAUTION: This email originated from outside of the organization. Do not > click links or open attachments unless you recognize the sender and know > the content is safe. If you suspect potential phishing or spam email, > report it to ReportSpam at accesssoftek.com > Many thanks for the reply, > right, this is what the discussion is about. > > > On Mon, Sep 28, 2020 at 10:57 AM David Blaikie <dblaikie at gmail.com> wrote: > >> To clarify, this is a discussion around whether given some move-only type >> X, implicitly convertible to Y and the code "Y func() { X x; return x; }" >> is that valid in LLVM? (and, as a corollary, if the type isn't move-only, >> is that code efficient (does it move rather than copying) - as in the >> vector example given) >> >> I /believe/ the answer is that it is not valid. I think the set of >> compilers supported includes those that do not implement this rule. (either >> due to the language version we compile with, or due to it being a DR that >> some supported compiler versions do not implement). But that's just my >> rough guess. >> >> On Sat, Sep 26, 2020 at 3:17 PM Alexander Shaposhnikov via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> Hello everyone! >>> It looks like in the LLVM codebase (including subprojects) there are >>> some inconsistencies >>> in how values are returned from functions with the following (or >>> similar) signature: >>> Expected<std::vector<int>> createVector() { >>> std::vector<int> V; >>> ... >>> } >>> It would be interesting to find out your opinion on this. >>> After some investigation I have found https://reviews.llvm.org/D70963 >>> and https://reviews.llvm.org/D43322 which have some additional context >>> regarding >>> the problem. The aforementioned diffs (and the comments on them) contain >>> a lot of >>> details and the history of the problem (whether one should use the cast >>> or not). >>> If I am not mistaken a part of the problem is that compilers' behaviors >>> have changed over time, and e.g. the latest versions would use a move >>> constructor while the older ones could use a copy constructor. So the >>> question is where we stand at the moment / what is the recommended approach >>> for the new code. >>> >>> Many thanks in advance, >>> Alexander Shaposhnikov >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> https://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/20201001/7c7ff0fa/attachment.html>
Apparently Analagous Threads
- [EXTERNAL] Re: preferred way to return expected values
- [EXTERNAL] Re: preferred way to return expected values
- preferred way to return expected values
- RFC: Add a preprocessor to yaml2obj (and other YAML tools)
- [RFC] - Deduplication of debug information in linkers (LLD).