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

Renato Golin renato.golin at linaro.org
Thu Jul 31 01:20:30 PDT 2014


Hi Arnaud,

Can't this affect debugging as well?

I mean, if you run this on O1 or less, you'll have a lot more variables
optimised away, especially at the end of the function, and at higher
optimisation levels you'll have a lot less variables to care about.

Cheers,
Renato
On 23 Jul 2014 01:23, "Arnaud A. de Grandmaison" <
arnaud.degrandmaison at arm.com> wrote:

> I am trying to implement the lifetime marker insertion for unnamed
> temporaries in order to reduce stack consumption.
>
>
>
> Inserting the lifetime.begin marker is the easy part; on the other hand,
>  inserting the lifetime.end gets a bit more complicated, as it involves
> scoping , exception handling and lifetime extension.
>
>
>
> Ideally, the lifetime.end marker should be inserted when the scope is
> exited, after the cleanups have been run. The problem is that in some
> cases, an object with a  trivial destructor for example, there is … no
> cleanup.  The existence of cleanups appears in the AST with the
> ExpWithCleanups, which wraps the underlying MaterializeTemporaryExpr.
>
>
>
> This is used in CodeGenFunction::EmitLValue to start a new
> RunCleanupsScope when visiting an ExpWithCleanups. My problem is how can I
> add a RunCleanupScope for MaterializeTemporaryExpr that are not part of an
> ExpWithCleanups. I can not always add a new scope, because it would mess-up
> the cleanup ordering --- when there are cleanups, the lifetime.end marker
> should be emitted after the destructor.
>
>
>
> Is there anything obvious I am missing ?
>
>
>
> Any hints would be welcome.
>
>
>
> Cheers,
>
> --
>
> Arnaud A. de Grandmaison
>
>
>
> _______________________________________________
> 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/20140731/93e5e35c/attachment.html>


More information about the cfe-dev mailing list