[LLVMdev] Helping the optimizer along (__assume)

[Mike Stump]

On Oct 23, 2008, at 3:40 AM, Matthijs Kooijman wrote:
> So, to really be able to encode this data, one could think of having  
> an
> "assume" intrinsic, i.e.:
>
> 	%cond = i1 ...
> 	call void @llvm.assume( i1 %cond )

I like this the best.

> Optimization passes won't just delete this, but we could teach  
> codegen that
> this intrinsic is not generated into any code. However, this still  
> doesn't
> completely solve the problem indicated at the first point above. If  
> %cond is
> provably true, we will end up with
>
> 	call void @llvm.assume( i1 true )

No, trivially the optimizer can be taught to not do this, if we don't  
want it to.  The optimizer can see that this is @llvm.assume by  
checking the spelling (code).  It all comes down to how much memory  
you want to burn to remember things that at one time you knew about  
the code and the likelihood of the utility of knowing that.  Put  
another way, if there are any downstream consumers of the information.

If we do:

   assert (p!=0);
   (base*)p;

when base is a virtual base, this must generate code to preserve 0  
values:

   if (p != 0)
     p += *(int*)(((char*)p)+n)

this does the conversion if p is non-zero, and if it is 0, it leaves  
it alone.

And for any reason we can figure out that p is not zero, we then can  
eliminate the assert as it were, and remove the conditional branch  
(nice win).  If there are no more down stream consumers of the  
information, the information itself can die at this optimization pass,  
and save the memory.  If this isn't the last consumer of the  
information, we can leave the assert untouched, remove the condition.   
For example, after -O4 inlining, there might be another virtual base  
conversion then exposed, and we figure out:

   assert (p!=0)
   p += *(int*)(((char*)p)+n)
   if (p != 0)
     p += *(int*)(((char*)p)+n1)

should be optimized as:

   assert (p!=0)
   p += *(int*)(((char*)p)+n)
   p += *(int*)(((char*)p)+n1)

as we can know that the first p += vbase adjustment cannot wrap back  
to 0.