[cfe-dev] Adding lifetime begin/end to unnamed temporaries

David Blaikie dblaikie at gmail.com
Fri Aug 1 07:52:39 PDT 2014


On Aug 1, 2014 5:55 AM, "Arnaud A. de Grandmaison" <
arnaud.degrandmaison at arm.com> wrote:
>
> I do not think this can apply to "C-only", as C has no way to express
unnamed temporaries (language lawyers may contradict me here ;)

Write a c function that returns a large struct by value and another with
that type as a parameter and call the later with the result of the former?

struct big source(void);
void sink(struct big);

sink(source ());

Should get you some anonymous stack usage in c that you can optimize the
use of.

> On the other hand for C++, you can have lots of those unnamed temporaries.
>
> A possible path, along the line of what you suggest, would be to activate
lifetime markers only in the non-throwing cases (or when compiled with
-fno-exceptions). The exceptional part could come later.
>
> We could at least get some of the benefits now.
>
> Cheers,
> Arnaud
>
>
> -----Original Message-----
> From: Renato Golin [mailto:renato.golin at linaro.org]
> Sent: 01 August 2014 13:26
> To: Arnaud De Grandmaison
> Cc: Clang Dev
> Subject: Re: [cfe-dev] Adding lifetime begin/end to unnamed temporaries
>
> On 31 July 2014 17:59, Arnaud A. de Grandmaison <
arnaud.degrandmaison at arm.com> wrote:
> > By the way, my patch indeed also affected some debuginfo (some
> > breakpoint location if I remember correctly). I have switched
> > temporarily to something else, but this  patch proved to be extremely
> > complex --- complexity linked to what you can find in the thread about
> > temporary destructors. There is something going wrong in how the
> > scopes are handled and my patch triggers it. I am probably breaking
> > some undocumented or implicit assumptions.  But there is definitely a
> > lot of potential to reduce stack usage, and we saw that on real code.
>
> This might be a bad idea, but is it possible to start with a C-only
implementation, and move on with C++ later? At least we can get the general
implementation right, and then only fiddle with exception handling when we
need to.
>
> cheers,
> --renato
>
>
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140801/d994c489/attachment.html>


More information about the cfe-dev mailing list