llvm dev - Dec 2011 - [LLVMdev] Adding option to LLVM opt to disable a specific pass from command line

2011/12/9 Joerg Sonnenberger <joerg at britannica.bec.de>
> On Fri, Dec 09, 2011 at 10:03:37AM +0100, Seb wrote:
> > I think my explanation is not clear, my front-end did NOTt generate
> > 'llvm.memcpy' it generate LL code that after use of LLVM
'opt' get
> > transformed by 'loop-idom' pass into an 'llvm.memcpy'
for an overlapping
> > loop:
> >
> > static void
> > t0(int n)
> > {
> >     int i;
> >     for (i=0; i<n; i++)
> >     result[i+1] = result[i];
> > }
>
> Do you really want to assign result[0] to everything?
>
> I wonder how much work it is to each the loop-idiom pass to handle this
> and the case of reverse indices correctly, if result is char *. E.g.
> create either memset or memmove...
>
> Joerg
>
This thread is not to discuss how relevant this example is. I just would
like to know:
a) If people think that adding an option to disable a specific pass is
useful.
b) To discuss implementation details (disable all pass invocations, what to
do when there are dependencies between passes invocations).
c) If I implement it, what's the process to get my change merge with trunk.

Now for my own purpose, I commented out loop-idiom invocation in LLVM 2.9
sources and it worked well. I just wanted to develop something generic that
could benefit LLVM community.

Best Regards
Seb
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20111209/41c6f085/attachment.html>

By the way, CLANG 2.9 produce same behavior as my front-end:

Try clang

clang -O2 -S -emit-llvm rec.c -o rec.ll

on following example:

/*--- Recurrence recognition.  */

static int expect[] = {
    1, 1, 1, 1          /* t0:  0 - 3  */
};

extern void check() ;

#define N sizeof(expect) / sizeof(int)

static int result[N];

static void
t0(int n)
{
    int i;
    for (i=0; i<n; i++)
    result[i+1] = result[i];
}

void
test() {
    result[0] = 1;
    t0(3);

    check(result, expect, N);
}

LL file generated is:
; ModuleID = 'ka50.c'
target datalayout
"e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64"
target triple = "x86_64-unknown-linux-gnu"

@result = internal global [4 x i32] zeroinitializer, align 16
@expect = internal global [4 x i32] [i32 1, i32 1, i32 1, i32 1], align 16

define void @test() nounwind {
  store i32 1, i32* getelementptr inbounds ([4 x i32]* @result, i64 0, i64
0), align 16, !tbaa !0
  tail call void @llvm.memcpy.p0i8.p0i8.i64(i8* bitcast (i32* getelementptr
inbounds ([4 x i32]* @result, i64 0, i64 1) to i8*), i8* bitcast ([4 x
i32]* @result to i8*), i64 12, i32 4, i1 false) nounwind
  tail call void (...)* @check(i32* getelementptr inbounds ([4 x i32]*
@result, i64 0, i64 0), i32* getelementptr inbounds ([4 x i32]* @expect,
i64 0, i64 0), i64 4) nounwind
  ret void
}

declare void @check(...)

Then assembly produced is:

test:                                   # @test
.Leh_func_begin0:
# BB#0:
    pushq    %rbp
.Ltmp0:
    movq    %rsp, %rbp
.Ltmp1:
    movl    $1, result(%rip)
    movl    result+8(%rip), %eax
    movl    %eax, result+12(%rip)
    movq    result(%rip), %rax
    movq    %rax, result+4(%rip)
    movl    $result, %edi
    movl    $expect, %esi
    movl    $4, %edx
    xorb    %al, %al
    callq    check
    popq    %rbp
    ret

As you can see resul+8 is read before being written and thus the problem.
Hope that clarifies the problem.


2011/12/9 Seb <babslachem at gmail.com>
>
>
> 2011/12/9 Joerg Sonnenberger <joerg at britannica.bec.de>
>
>> On Fri, Dec 09, 2011 at 10:03:37AM +0100, Seb wrote:
>> > I think my explanation is not clear, my front-end did NOTt
generate
>> > 'llvm.memcpy' it generate LL code that after use of LLVM
'opt' get
>> > transformed by 'loop-idom' pass into an
'llvm.memcpy' for an overlapping
>> > loop:
>> >
>> > static void
>> > t0(int n)
>> > {
>> >     int i;
>> >     for (i=0; i<n; i++)
>> >     result[i+1] = result[i];
>> > }
>>
>> Do you really want to assign result[0] to everything?
>>
>> I wonder how much work it is to each the loop-idiom pass to handle this
>> and the case of reverse indices correctly, if result is char *. E.g.
>> create either memset or memmove...
>>
>> Joerg
>>
>
> This thread is not to discuss how relevant this example is. I just would
> like to know:
> a) If people think that adding an option to disable a specific pass is
> useful.
> b) To discuss implementation details (disable all pass invocations, what
> to do when there are dependencies between passes invocations).
> c) If I implement it, what's the process to get my change merge with
trunk.
>
> Now for my own purpose, I commented out loop-idiom invocation in LLVM 2.9
> sources and it worked well. I just wanted to develop something generic that
> could benefit LLVM community.
>
> Best Regards
> Seb
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20111209/c06083d9/attachment.html>

On 12/9/2011 8:23 AM, Seb wrote:
> This thread is not to discuss how relevant this example is. I just would
> like to know:
> a) If people think that adding an option to disable a specific pass is
> useful.
Yes, a peer of mine recently wanted such an option to disable individual 
passes in order to 1) narrow in on a bug in one of them that affected 
stack back tracing, and 2) provide a workaround for the bug.  He didn't 
pursue modifying code to remove the passes one at a time and thus the 
bug remains hidden.

Tom.

Hi Tom,
> On 12/9/2011 8:23 AM, Seb wrote:
>> This thread is not to discuss how relevant this example is. I just
would
>> like to know:
>> a) If people think that adding an option to disable a specific pass is
>> useful.
>
> Yes, a peer of mine recently wanted such an option to disable individual
> passes in order to 1) narrow in on a bug in one of them that affected
> stack back tracing, and 2) provide a workaround for the bug.  He didn't
> pursue modifying code to remove the passes one at a time and thus the
> bug remains hidden.
you don't have to modify code to reduce the list of passes.  Get clang (or
whatever) to produce unoptimized bitcode.  Check that running
   opt -std-compile-opts
(or opt -O3) or whatever reproduces the problem.  Adding -debug-pass=Arguments
will show you the list of passes used.  You can then run opt with this explicit
list of passes (rather than -std-compile-opts), and remove passes until you find
the problematic one.  Bugpoint can do this for you automatically.

Ciao, Duncan.