llvm dev - Aug 2009 - [LLVMdev] A create-distinct-item function with no (other) side effects

Suppose I have some LLVM assembly like this:

declare i8* @CreateDistinctItem() nounwind

declare void @dumpBoolean(i1 %val)

define i32 @main()
{
 %var1 = call i8* CreateDistinctItem()
 %var2 = call i8* CreateDistinctItem()
 %isEqual = icmp eq i8* %val1, %val2
 call void @dumpBoolean(i1 %isEqual)
 ret i32 0
}

So far so good.  But if I take out the "call @dumpBoolean", the
optimizer still leaves me with two calls to CreateDistinctItem,
because it assumes that CreateDistinctItem might have side-effects.

Now if I add the "readonly" flag to CreateDistinctItem and put back
the "call @dumpBoolean", the optimizer now assumes that
CreateDistinctItem always returns the *same* item, and optimizes the
whole body of main down to:

define i32 @main()
{
 tail call void @dumpBoolean(i1 true)
 ret i32 0
}

which is totally wrong.

This is by design, of course, (CreateDistinctItem does not return the
same value given the same caller-visible global state) but I see no
way to declare a function that:

1. Returns a distinct item each time it's called,
2. Doesn't need to be called at all if its return value from that call
isn't used, and
3. Doesn't even need to be declared if its return value is *never* used.

If I happen to know about CreateDistinctItem at build time, I can
write a custom pass, of course, but I was wondering if there was an
easier way to get the standard optimizers to recognize it, or if y'all
think it's worthwhile to add an easier way.

2009/8/28 Kenneth Uildriks <kennethuil at gmail.com>
> Suppose I have some LLVM assembly like this:
>
> declare i8* @CreateDistinctItem() nounwind
>
> declare void @dumpBoolean(i1 %val)
>
> define i32 @main()
> {
>  %var1 = call i8* CreateDistinctItem()
>  %var2 = call i8* CreateDistinctItem()
>  %isEqual = icmp eq i8* %val1, %val2
>  call void @dumpBoolean(i1 %isEqual)
>  ret i32 0
> }
>
> So far so good.  But if I take out the "call @dumpBoolean", the
> optimizer still leaves me with two calls to CreateDistinctItem,
> because it assumes that CreateDistinctItem might have side-effects.
>
> Now if I add the "readonly" flag to CreateDistinctItem and put
back
> the "call @dumpBoolean", the optimizer now assumes that
> CreateDistinctItem always returns the *same* item, and optimizes the
> whole body of main down to:
>
> define i32 @main()
> {
>  tail call void @dumpBoolean(i1 true)
>  ret i32 0
> }
>
> which is totally wrong.
>
> This is by design, of course, (CreateDistinctItem does not return the
> same value given the same caller-visible global state) but I see no
> way to declare a function that:
>
> 1. Returns a distinct item each time it's called,

Attach a 'noalias' attribute to the return type in your function
declaration. See http://llvm.org/docs/LangRef.html#paramattrs

> 2. Doesn't need to be called at all if its return value from that call
> isn't used, and
> 3. Doesn't even need to be declared if its return value is *never*
used.

Thus far these still need a custom pass. It shouldn't be too hard though.
See http://wiki.llvm.org/HowTo:_Find_all_call_sites_of_a_function

You're the second user I know of to ask for this. We should probably come up
with a general solution of some sort.

Nick

> If I happen to know about CreateDistinctItem at build time, I can
> write a custom pass, of course, but I was wondering if there was an
> easier way to get the standard optimizers to recognize it, or if y'all
> think it's worthwhile to add an easier way.
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20090828/f67666a3/attachment.html>

On Fri, Aug 28, 2009 at 3:47 PM, Nick Lewycky<nlewycky at google.com>
wrote:
>
>
> 2009/8/28 Kenneth Uildriks <kennethuil at gmail.com>
>>
>> This is by design, of course, (CreateDistinctItem does not return the
>> same value given the same caller-visible global state) but I see no
>> way to declare a function that:
>>
>> 1. Returns a distinct item each time it's called,
>
> Attach a 'noalias' attribute to the return type in your function
> declaration. See http://llvm.org/docs/LangRef.html#paramattrs
>
>>
>> 2. Doesn't need to be called at all if its return value from that
call
>> isn't used, and
>> 3. Doesn't even need to be declared if its return value is *never*
used.
>
> Thus far these still need a custom pass. It shouldn't be too hard
though.
> See http://wiki.llvm.org/HowTo:_Find_all_call_sites_of_a_function
>
> You're the second user I know of to ask for this. We should probably
come up
> with a general solution of some sort.
Conceptually, it's the same as "readonly" except that the
requirement
that it return the same value each time is dropped.  It would also
help optimize away calls to "random" in some cases.  I understand that
adding a new function attribute to IR is not trivial, though.  Thanks
for the confirmation.

My front-end is writing LLVM calls into the output module, and JITting
it as part of the compile process so it can create runtime code, and
allowing compiled code to optionally call functions exposing those
same LLVM calls to do its own runtime JITting.  I'm finding lots of
uses for that setup, at both compiletime and runtime, but when the
compiled code doesn't actually JIT anything at runtime, optimizing
away all those LLVM calls along with the LLVM library extern function
declarations would make the resulting .s files have *much* lighter
linking requirements and be easier to package and distribute.  I guess
a custom pass that's part of my compiler project would be the way to
go.
>
> Nick
>
>>
>> If I happen to know about CreateDistinctItem at build time, I can
>> write a custom pass, of course, but I was wondering if there was an
>> easier way to get the standard optimizers to recognize it, or if
y'all
>> think it's worthwhile to add an easier way.
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>