[llvm-dev] extending liveness of 'this' pointer via FAKE_USE opcode

[Pieb, Wolfgang via llvm-dev]

> -----Original Message-----
> From: aprantl at apple.com [mailto:aprantl at apple.com]
> Sent: Monday, September 21, 2015 4:27 PM
> To: Pieb, Wolfgang
> Cc: llvm-dev at lists.llvm.org
> Subject: Re: [llvm-dev] extending liveness of 'this' pointer via
> FAKE_USE opcode
> 
> 
> > On Sep 21, 2015, at 11:16 AM, Pieb, Wolfgang via llvm-dev <llvm-
> dev at lists.llvm.org> wrote:
> >
> > Hello!
> >
> > At Sony we've seen some serious customer interest in having the
> 'this'
> > pointer visible throughout an entire function during debugging.
> > However, optimizations may eliminate it after its last use, so we've
> been looking for a way to artificially extend its liverange to the end
> of the function.
> >
> > So far, the most compelling way we can think of, and one we have used
> > successfully in the past in at least one other compiler, is to create
> a 'fake use' of the 'this' pointer at the end of the function,
> compelling the rest of the compiler to not optimize it away.
> >
> > At the moment there doesn't seem to be a good way to create such a
> > fake use in LLVM (please enlighten us if you know of one), so we are
> proposing to introduce a new intrinsic (e.g. llvm.fake_use), which
> would take a single value argument, representing a use of that value.
> > The intrinsic would be lowered to a new invariant TargetOpcode (e.g.
> FAKE_USE), which serves the same purpose at the MI level.
> > Code emission would simply ignore the new opcode.
> >
> > Frontends could use the intrinsic to extend liveranges of variables
> as
> > desired. As a first use case, clang would accept a new option (e.g.
> > -fkeep-this-ptr) which would cause a fake use of 'this' to be
> inserted at the end of a function, making it available for inspection
> throughout the entire function body.
> 
> >
> > One important note is that since such an option would affect code
> > generation, it cannot be automatically enabled by -g. However, should
> there be eventually support for a -Og mode (optimize for debugging),
> that mode could enable it.
> >
> > Any comments or alternative ideas are appreciated.
> 
> The clang frontend creates all variables in stack slots and relies on
> LLVM to lower them into registers if applicable. Would the new
> intrinsic refer to the stack slot, would it describe a load of the
> value?

The intent is to represent a 'use' as if it were passed to a function as an argument, so a load would precede the invocation of the intrinsic.

> 
> What happens if the function is inlined, will the new intrinsic prevent
> other optimizations?

Only indirectly as a result of extending its argument's lifetime. Obviously we'd have to make sure inline heuristics are not influenced by the presence of the intrinsic. Register pressure may increase which may influence scheduling etc. but there shouldn’t be any explicit suppression of particular optimizations. 
> 
> — adrian
> 
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev