[LLVMdev] generate llvm.assume calls in GVN?

Chandler Carruth chandlerc at google.com
Thu Jan 15 10:49:48 PST 2015


On Thu, Jan 15, 2015 at 10:30 AM, Sanjay Patel <spatel at rotateright.com>
wrote:

> Would it be wrong to generate the llvm.assume IR suggested below? in GVN?
>

I think so... Because:

One very small tweak you could make would be to add an llvm.assume inside
>> the if case of the if condition.  (Yes, that is as silly as it sounds.)  I
>> tested that, and it did optimize as expected.  It's essentially working
>> around a deficiency in the optimizer around path constraints.
>>
>
Once upon a time, there was an optimization for this called predsimplify. I
believe Nick can tell you a long, glorious, tragic tale about its life and
ultimate death.

In particular:


>> define void @example_tweaked(i64* %x0) #0 {
>>   %1 = load i64* %x0, align 8
>>   %2 = and i64 %1, 3
>>   %3 = icmp eq i64 %2, 2
>>   br i1 %3, label %4, label %8
>> ; <label>:4                                       ; preds = %0
>>   call void @llvm.assume(i1 %3)
>>
>
We don't need the assume here. If we want to do predicate-based
simplification, we can just have <whatever> look at dominating branch
conditions, much like it looks at dominating assume calls. Worst case is
that it requires more fancy-ness in the assumption tracking infrastructure
to actually funnel queries through to different ways of saying "this value
is true at this point".

However, that is the core essence of predsimplify. Historically, we have
found a really terrifying amount of complexity and compile time hit for
relatively small gains in terms of generated code quality. =/ Maybe we just
need to handle the "obvious" cases much like the very limited calls to
assumption tracker do, but I think this path needs to be trod with great
care.


>>   %5 = and i64 %1, -4                ; this should be optimized away
>>   %6 = or i64 %5, 2                  ; this should be optimized away
>>   %7 = add nsw i64 %6, 12
>>   store i64 %7, i64* %x0, align 8
>>   ret void
>> ; <label>:8                                       ; preds = %0
>>   tail call void @go_error() #2
>>   unreachable
>> }
>>
>> declare void @llvm.assume(i1)
>>
>>
>>
>>  Thanks for any ideas,
>> /Lars
>>
>> /***************************************************/
>>
>>  /*  The two LSB of x0 are 'tag bits'  */
>> /*  that we want to manipulate.       */
>> extern long x0;
>>
>>  void go_error(void) __attribute__ ((noreturn));
>>
>>  void example_not_optimized(void)
>> {
>>   if((x0 & 3) == 2) {
>>     // Here the tag bits are removed and added
>>     // with bitwise 'and' and 'or'.
>>     x0 = ((x0 & ~3) | 2) + 12;
>>   } else {
>>     go_error();
>>   }
>> }
>>
>>  /*
>> define void @example_not_optimized() #0 {
>>   %1 = load i64* @x0, align 8, !tbaa !1
>>   %2 = and i64 %1, 3
>>   %3 = icmp eq i64 %2, 2
>>   br i1 %3, label %4, label %8
>>
>>  ; <label>:4                                       ; preds = %0
>>   %5 = and i64 %1, -4                ; this should be optimized away
>>   %6 = or i64 %5, 2                  ; this should be optimized away
>>   %7 = add nsw i64 %6, 12
>>   store i64 %7, i64* @x0, align 8, !tbaa !1
>>   ret void
>>
>>  ; <label>:8                                       ; preds = %0
>>   tail call void @go_error() #2
>>   unreachable
>> }
>> */
>>
>>
>>  void example_optimized(void)
>> {
>>   if((x0 & 3) == 2) {
>>     // Here the tag bits are removed and added
>>     // with subtraction and addition.
>>     x0 = (x0 - (x0 & 3) + 2) + 12;
>>   } else {
>>     go_error();
>>   }
>> }
>>
>>  /*
>> define void @example_optimized() #0 {
>>   %1 = load i64* @x0, align 8, !tbaa !1
>>   %2 = and i64 %1, 3
>>   %3 = icmp eq i64 %2, 2
>>   br i1 %3, label %4, label %6
>>
>>  ; <label>:4                                       ; preds = %0
>>   %5 = add i64 %1, 12
>>   store i64 %5, i64* @x0, align 8, !tbaa !1
>>   ret void
>>
>>  ; <label>:6                                       ; preds = %0
>>   tail call void @go_error() #2
>>   unreachable
>> }
>>
>>   */
>>
>>
>>
>> _______________________________________________
>> LLVM Developers mailing listLLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
>
> _______________________________________________
> 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/20150115/72874a82/attachment.html>


More information about the llvm-dev mailing list