llvm dev - Jul 2011 - [LLVMdev] code generation removes duplicated instructions

Hello,

The code snippet pasted in the previous email are generated at -O0 with llc.
Since I am inserting a new basic block (contains printf statement and
program exit) which is jumped upon based on the result of
the comparison, the compiler cannot/shouldnot optimize that away by means of
DCE or anything else.

The same kind of stuff is happening for the following duplication.

bb6.split:                                        ; preds = %bb6
  %33 = load i32* %32, align 4
  %34 = load i32* %i, align 4
  %HV4_3 = sub nsw i32 %34, %33
  %35 = sub nsw i32 %34, %33
  %HV4_2 = getelementptr inbounds [100 x i32]* %a, i32 0, i32 %HV4_3
  %36 = getelementptr inbounds [100 x i32]* %a, i32 0, i32 %35
  %LDCmp6 = icmp ne i32* %36, %HV4_2
  br i1 %LDCmp6, label %relExit, label %bb6.split.split

In the above example even the operands are not same and I guess compiler
cannot be that smart at -O0. I sense something is wrong with the code
generation for ARM.

What other way do you suggest for duplicating since you mentioned I
shouldn't rely on duplication the way I am doing it?

Thanks a lot. I really appreciate your help.
Daya


On Wed, Jul 6, 2011 at 10:27 AM, Renato Golin <renato.golin at arm.com>
wrote:
> On 6 July 2011 14:55, D S Khudia <daya.khudia at gmail.com> wrote:
> > The following is an example code generation for arm and x86 for a same
IR
> > BB. In the x86 code I can see that the same computation is done twice
and
> > result is stored in two different registers and then these two
different
> > registers are used for comparision.
>
> Yes, but you shouldn't rely on it, since the compiler is free to
> optimize that away.
>
>
> > By the way I am duplicating instruction
> > and inserting comparison to catch transient errors.
>
> I thought so. Try running llc with -O0 or disable specific
> optimizations (like dead-code elimination) to keep your comparisons
> intact.
>
> But since the two values are identical, it's possible that even so,
> both will live in the same register.
>
> cheers,
> --renato
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20110706/3286a9e8/attachment.html>

On 6 July 2011 15:57, D S Khudia <daya.khudia at gmail.com>
wrote:
> Since I am inserting a new basic block (contains printf statement and
> program exit) which is jumped upon based on the result of
> the comparison, the compiler cannot/shouldnot optimize that away by means
of
> DCE or anything else.
It most certainly can, since the comparison yields always the same
result. The compiler can replace all that by a simple branch to
whatever block always executes.

> In the above example even the operands are not same and I guess compiler
> cannot be that smart at -O0. I sense something is wrong with the code
> generation for ARM.
There're no hard rules stopping any compiler to run DCE or DAG
combining/elimination or whatever when in O0 or any other level.

> What other way do you suggest for duplicating since you mentioned I
> shouldn't rely on duplication the way I am doing it?
> Thanks a lot. I really appreciate your help.
What you need is a way to make sure it won't be optimised away,
possibly even on higher O-levels. You need to add a dependency that
the compiler cannot see through (or is not smart enough at O0 to do
so, at least). Because this is a transient change, as a way to debug
other problems, you're allowed to do ugly stuff.

For example, you can get a fake offset from an argument, and guarantee
that this is always zero. Or you can add a random offset internally to
one of them, and then compare that one is exactly the offset higher
(or lower) than the other. Or you could pass %a and %b as parameters
and memcopy them in the caller.

Anything that would make it difficult for the compiler to see that
both are the same would do...

cheers,
--renato

Hi Renato,

I am trying to add a intrinsic call between the similar two instructions
which either I'll remove or convert to nop in codegen.
Does that kind of seem appropriate for the purpose here?

Thanks
Daya

On Wed, Jul 6, 2011 at 11:55 AM, Renato Golin <renato.golin at arm.com>
wrote:
> On 6 July 2011 15:57, D S Khudia <daya.khudia at gmail.com> wrote:
> > Since I am inserting a new basic block (contains printf statement and
> > program exit) which is jumped upon based on the result of
> > the comparison, the compiler cannot/shouldnot optimize that away by
means
> of
> > DCE or anything else.
>
> It most certainly can, since the comparison yields always the same
> result. The compiler can replace all that by a simple branch to
> whatever block always executes.
>
>
> > In the above example even the operands are not same and I guess
compiler
> > cannot be that smart at -O0. I sense something is wrong with the code
> > generation for ARM.
>
> There're no hard rules stopping any compiler to run DCE or DAG
> combining/elimination or whatever when in O0 or any other level.
>
>
> > What other way do you suggest for duplicating since you mentioned I
> > shouldn't rely on duplication the way I am doing it?
> > Thanks a lot. I really appreciate your help.
>
> What you need is a way to make sure it won't be optimised away,
> possibly even on higher O-levels. You need to add a dependency that
> the compiler cannot see through (or is not smart enough at O0 to do
> so, at least). Because this is a transient change, as a way to debug
> other problems, you're allowed to do ugly stuff.
>
> For example, you can get a fake offset from an argument, and guarantee
> that this is always zero. Or you can add a random offset internally to
> one of them, and then compare that one is exactly the offset higher
> (or lower) than the other. Or you could pass %a and %b as parameters
> and memcopy them in the caller.
>
> Anything that would make it difficult for the compiler to see that
> both are the same would do...
>
> cheers,
> --renato
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20110706/32b5f926/attachment.html>