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

Hello Devang,

answers are interleaved

2011/12/7 Devang Patel <dpatel at apple.com>
> Hello,
>
> On Dec 7, 2011, at 2:07 AM, Seb wrote:
>
> > Hi all,
> >
> > I would like to add an option for LLVM 'opt' to disable a
specific
> optimization pass from command line.
> >
> > The idea is to have something like:
> >
> > opt -O2 -disable-pass=[passname,...]
> >
> > Do you think it could be useful ?
>
> I have few questions :
>
> - Why (and when) would you us this ?
>
I woudl use this to selectively disable passes in opt that are either
redundant with passes performed by the fron-end I'm working on our exhibit
a BUG in opt. For instance, I figured out that loop-idiom pass has a BUG in
LLVM 2.9, a llvm.memcpy is generated for an overlapping memory region and
then x86 backend reorder loads/store thus generating a BUG.

So my use would be to disable all loop-idiom invocations.

> - Some of the passes are executed multiple times, how would you select
> which invocation to disable ? Or would you disable all invocation of such
> passes ?
>
By default I guess I would like to disable all invocation of such passes.
We could also imagine to have an option -disable-pass=[pass_name:inv_num,
...] to deal with multiple invocation.

- Some passes are required by another passes. In such cases
PassManager
> will insist on running them, which may conflict with the user request from
> command line. Who wins?
>
How to I know that a pass  is required by another ?
Let's say give priority to pass manager and issue a warning like like
'option -disable-pass=<pass_name> ignored because required by pass
<other_pass>.'

- Why not update the list passes run as part of -O2 (use
> --debug-pass=Arguments to get it) to remove selected passes and run opt
<my
> list of passes> ... ?
>
>
 I also thought about this but it can lead to long command lines and source
of errors.

> > How should I proceed to develop it and commit changes to LLVM trunk ?
> > Thanks for your advices and recommandations.
> > Best Regards
> > Seb
>
>
> -
> Devang
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20111208/8afa6dbc/attachment.html>

Hello,
>     - Some passes are required by another passes. In such cases
>     PassManager will insist on running them, which may conflict with the
>     user request from command line. Who wins?
>
>
> How to I know that a pass  is required by another ?
> Let's say give priority to pass manager and issue a warning like like
> 'option -disable-pass=<pass_name> ignored because required by
pass
> <other_pass>.'
>
I would opt for disabling dependent passes as well, and providing a 
warning that they have been disabled implicitly (possibly giving the 
disabled pass that caused this effect).

I think such behavior would make sense if you were disabling passes 
because they contain bugs.

Another option would be to differentiate between a strong (disabling 
pass + dependents) and weak (disabling pass if no dependents) disable 
parameter.

- Roel

> For instance, I figured out that loop-idiom pass has a BUG in
> LLVM 2.9, a llvm.memcpy is generated for an overlapping memory region and
> then x86 backend reorder loads/store thus generating a BUG.
Just for the record it seems this is a bug in your frontend, not in
the LLVM backend. The memcpy intrinsic, like the standard memcpy
function, requires that the regions be non-overlapping:
http://llvm.org/docs/LangRef.html#int_memcpy By violating this
contract it's possible you'll encounter all sorts of issues in other
passes too.

- David

David,

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];
}

Then 'llc' expanded llvm.memcpy into a sequence of load/store that where
performed out-of-order and thus the final code was incorrect.
So to sumarize, BUG was not in my front-end, it was in LLVM 'opt'
loop-idom
pass, it seems now fixed into 3.0. However I think I would be a good idea
to add more control from command line on pass we want to disable.

Best Regards
Seb

2011/12/8 David Blaikie <dblaikie at gmail.com>
> > For instance, I figured out that loop-idiom pass has a BUG in
> > LLVM 2.9, a llvm.memcpy is generated for an overlapping memory region
and
> > then x86 backend reorder loads/store thus generating a BUG.
>
> Just for the record it seems this is a bug in your frontend, not in
> the LLVM backend. The memcpy intrinsic, like the standard memcpy
> function, requires that the regions be non-overlapping:
> http://llvm.org/docs/LangRef.html#int_memcpy By violating this
> contract it's possible you'll encounter all sorts of issues in
other
> passes too.
>
> - David
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20111209/9a35522e/attachment.html>