[LLVMdev] RFC: liveoncall parameter attribute

[Philip Reames]

On 06/04/2015 11:00 AM, Chris Lattner wrote:
>> On Jun 1, 2015, at 4:28 PM, Philip Reames <listmail at philipreames.com> wrote:
>>
>> An alternate approach would be to insert a dummy use into the callee, lower it to a noop late in the backend, and teach the inliner to remove it after inlining.  I suspect this would be both harder to implement and harder to optimize around.
>
> Hi Philip,
>
> Without knowing more, using an intrinsic for this seems like a better way to go: the intrinsic call will keep value alive, and you can special case the behavior for inlining in the inliner, which is apparently the only place where this is problematic.  I suspect that this will be a lot less impact on the existing compiler, be much less likely to break going forward, and also trivially composes across other existing argument attributes.
>
> What are the disadvantages of going with a new intrinsic?
The intrinsic I was thinking of would be something along the lines of:
void @llvm.live_on_call(<type> val) readnone

One challenge would be that I'd want the intrinsic to have readnone 
memory semantics, but such an intrinsic with a void return would be 
trivially dropped.  We already somewhat hack around this for things like 
assumes, so I could probably extend the logic.

Places that would need extended include:
- InlineCostAnalysis - discount the cost of the call
- InlineFunction - remove the call after inlining
- AliasAnalyis/MDA/etc.. (per above comment)
- Verifier - must be in entry block

You're right, that doesn't actually sound that bad.  It's a bit more 
code, but not *that* much more.  Semantically, it makes a bit more sense 
to me as a parameter attribute - it really is an requirement of the 
*call*, not of the *callee* - but I could see doing the intrinsic 
instead.  It's not that confusing.


As it happens, my immediate motivation to implement this has 
disappeared.  It turned out the symptom I was investigating when I came 
up with this proposal was merely a hint of a larger problem that became 
apparent once we started really looking at what dead argument 
elimination was doing in the original case.  We use a limited form of 
function interposition which replaces the implementation of the callee, 
and dead arg elimination is unsound in this context.  (i.e. just because 
we analyzed what the method did as if were compiled doesn't mean it's 
safe to run that method in the interpreter.  That unused pointer 
argument might actually be accessed and it had better be valid and 
dereferenceable even if the result is provably irrelevant to the final 
result.)  Any solution I've come up with to the underlying problems 
solves this somewhat by accident, so I'm probably going to just set this 
aside for the moment and come back to it in the future if I need it again.

Philip