How to replace -O1 with corresponding -f's?

How to replace -O1 with corresponding -f's?

[Sergei Organov]

Hi,

Using gcc compiled from gcc-4_0-branch, in an attempt to see which
particular optimization option makes my test case to be mis-optimized, I
try to replace -O1 (which toggles on the problem) with corresponding set
of -fxxx optimization options. I first compile my code like this:

gcc -v -save-temps -fverbose-asm -O1 -o const.o -c const.c

then merge the cc1 command that gcc invokes to compile the preprocessed
source (as gcc doesn't seem to pass some of -f forward to cc1) with the
entire list of options taken from resulting const.s file (found at the
line " # options enabled: ..." and further), and compile using this.

In the resulting const.s file there are 2 problems:

1. "options enabled" output almost matches those from the initial (-O1)
   invocation, but -floop-optimize is missing though it does exist in
   the "options passed" output.

2. The resulting assembly is different from what I get with -O1 and
   doesn't contain the mis-optimization I'm trying to debug though it
   doesn't seem to have anything to do with loops. For reference, the
   code I'm trying to compile is:

        extern double const osv;
        double const osv = 314314314;
        double osvf() { return osv; }

Am I doing something stupid or what? How one finds out what optimization
pass misbehaves?

-- 
Sergei.

Re: How to replace -O1 with corresponding -f's?

[Andrew Haley]

Sergei Organov writes:
 > Hi,
 > 
 > Using gcc compiled from gcc-4_0-branch, in an attempt to see which
 > particular optimization option makes my test case to be mis-optimized, I
 > try to replace -O1 (which toggles on the problem) with corresponding set
 > of -fxxx optimization options.

In general you can't do this.  You can turn some optimization passes
off, though.

 > How one finds out what optimization pass misbehaves?

Look at the dumps.  If you use the gcc option -da you'll get a full
set of RTL dump files.

Andrew.

Re: How to replace -O1 with corresponding -f's?

[Scott Robert Ladd]

Sergei Organov wrote:
> Using gcc compiled from gcc-4_0-branch, in an attempt to see which
> particular optimization option makes my test case to be mis-optimized,

This sort of problem is exactly what my Acovea program was designed for;
it will identify the pessimistic option by analyzing GCC's compilation
of your code.

    http://acovea.coyotegulch.com

..Scott

Re: How to replace -O1 with corresponding -f's?

[Andrew Pinski]

On Jun 20, 2005, at 10:04 AM, Andrew Haley wrote:
>> How one finds out what optimization pass misbehaves?
>
> Look at the dumps.  If you use the gcc option -da you'll get a full
> set of RTL dump files.

And -fdump-tree-all for the tree dumps.

Thanks,
Andrew Pinski

Re: How to replace -O1 with corresponding -f's?

[Sergei Organov]

Andrew Haley <aph@redhat.com> writes:

> Sergei Organov writes:
>  > Hi,
>  > 
>  > Using gcc compiled from gcc-4_0-branch, in an attempt to see which
>  > particular optimization option makes my test case to be mis-optimized, I
>  > try to replace -O1 (which toggles on the problem) with corresponding set
>  > of -fxxx optimization options.
> 
> In general you can't do this.  You can turn some optimization passes
> off, though.

Sigh :(

> 
>  > How one finds out what optimization pass misbehaves?
> 
> Look at the dumps.  If you use the gcc option -da you'll get a full
> set of RTL dump files.

I'm afraid that it's one of the tree optimization passes as
const.cc.00.expand is already [mis]optimized the way I don't like.

-- 
Sergei.

Re: How to replace -O1 with corresponding -f's?

[Andrew Pinski]

On Jun 20, 2005, at 9:38 AM, Sergei Organov wrote:

> 2. The resulting assembly is different from what I get with -O1 and
>    doesn't contain the mis-optimization I'm trying to debug though it
>    doesn't seem to have anything to do with loops. For reference, the
>    code I'm trying to compile is:
>
>         extern double const osv;
>         double const osv = 314314314;
>         double osvf() { return osv; }

I don't see anything wrong with what it gives for -O0 and -O2.

-- Pinski

Re: How to replace -O1 with corresponding -f's?

[Sergei Organov]

Andrew Pinski <pinskia@physics.uc.edu> writes:

> On Jun 20, 2005, at 10:04 AM, Andrew Haley wrote:
> >> How one finds out what optimization pass misbehaves?
> >
> > Look at the dumps.  If you use the gcc option -da you'll get a full
> > set of RTL dump files.
>
> And -fdump-tree-all for the tree dumps.

The last const.c.t69.final_cleanup is exactly the same in both cases and
doesn't have any useful information anyway:


;; Function osvf (osvf)

osvf ()
{
<bb 0>:
  return 3.14314314e+8;

}

In fact, at the RTL level the difference is that non-optimized code


(insn 8 6 9 1 (set (reg:DF 118 [ D.1144 ])
        (mem/u/i:DF (symbol_ref:SI ("osv") [flags 0x6] <var_decl 0x401ab32c osv>
    (nil))

(insn 9 8 10 1 (set (reg:DF 119 [ <result> ])
        (reg:DF 118 [ D.1144 ])) -1 (nil)
    (nil))

gets replaced with "optimized" one:

(insn 10 9 11 1 (set (reg:SI 121)
        (high:SI (symbol_ref/u:SI ("*.LC0") [flags 0x2]))) -1 (nil)
    (nil))

(insn 11 10 12 1 (set (reg/f:SI 120)
        (lo_sum:SI (reg:SI 121)
            (symbol_ref/u:SI ("*.LC0") [flags 0x2]))) -1 (nil)
    (expr_list:REG_EQUAL (symbol_ref/u:SI ("*.LC0") [flags 0x2])
        (nil)))

(insn 12 11 13 1 (set (reg:DF 118 [ <result> ])
        (mem/u/i:DF (reg/f:SI 120) [0 S8 A64])) -1 (nil)
    (expr_list:REG_EQUAL (const_double:DF 3.14314314e+8 [0x0.95e0725p+29])
        (nil)))

so SYMBOL_FLAG_SMALL (flags 0x6 vs 0x2) is somehow being missed when -O1
is turned on. Seems to be something at tree-to-RTX conversion time.
Constant folding?

-- 
Sergei.

Re: How to replace -O1 with corresponding -f's?

[Andrew Pinski]

On Jun 20, 2005, at 10:54 AM, Sergei Organov wrote:

> so SYMBOL_FLAG_SMALL (flags 0x6 vs 0x2) is somehow being missed when 
> -O1
> is turned on. Seems to be something at tree-to-RTX conversion time.
> Constant folding?

No, it would mean that the target says that this is not a small data.
Also try it with the following code and you will see there is no 
difference:
         double osvf() { return 314314314; }

Thanks,
Andrew Pinski

Re: How to replace -O1 with corresponding -f's?

[Sergei Organov]

Andrew Pinski <pinskia@physics.uc.edu> writes:

> On Jun 20, 2005, at 9:38 AM, Sergei Organov wrote:
>
> > 2. The resulting assembly is different from what I get with -O1 and
> >    doesn't contain the mis-optimization I'm trying to debug though it
> >    doesn't seem to have anything to do with loops. For reference, the
> >    code I'm trying to compile is:
> >
> >         extern double const osv;
> >         double const osv = 314314314;
> >         double osvf() { return osv; }
>
> I don't see anything wrong with what it gives for -O0 and -O2.

Well, it's on PowerPC with its small constant data sections.

With -O1 I get:

        .globl osv
        .section        .sdata2,"a",@progbits
        .align 3
        .type   osv, @object
        .size   osv, 8
osv:
        .long   1102232590
        .long   1241513984
        .section        .rodata.cst8,"aM",@progbits,8
        .align 3
.LC0:
        .long   1102232590
        .long   1241513984
        .section        ".text"
        .align 2
        .globl osvf
        .type   osvf, @function
osvf:
        lis %r9,.LC0@ha  # tmp121,
        lfd %f1,.LC0@l(%r9)      #, <result>
        blr      #

With -O0 and a bunch of -f's from -O1 I get:

        .globl osv
        .section        .sdata2,"a",@progbits
        .align 3
        .type   osv, @object
        .size   osv, 8
osv:
        .long   1102232590
        .long   1241513984
        .section        ".text"
        .align 2
        .globl osvf
        .type   osvf, @function
osvf:
.LFB2:
        lfd %f0,osv@sda21(%r0)   # osv, D.1144
        fmr %f1,%f0      # <result>, <result>
        blr      #

While the ideal code would be:

        ...
osvf:
.LFB2:
        lfd %f1,osv@sda21(%r0)   # osv, D.1144
        blr      #

-- 
Sergei.

Re: How to replace -O1 with corresponding -f's?

[Sergei Organov]

Andrew Pinski <pinskia@physics.uc.edu> writes:

> On Jun 20, 2005, at 10:54 AM, Sergei Organov wrote:
> 
> > so SYMBOL_FLAG_SMALL (flags 0x6 vs 0x2) is somehow being missed when -O1
> 
> > is turned on. Seems to be something at tree-to-RTX conversion time.
> > Constant folding?
> 
> No, it would mean that the target says that this is not a small data.
> Also try it with the following code and you will see there is no difference:
> 
>          double osvf() { return 314314314; }

There is no difference in the sense that here both -O0 and -O1 behave
roughly the same. So the problem is with detecting "smallness" for true
constants by the target, right?

But even then, if I fix that, there still will be a problem that for
given platform there doesn't seem to be a single reason to replace

double const osv = 314314314;
double osvf() { return osv; }

with

double const osv = 314314314;
double const .LC0 = 314314314;
double osvf() { return .LCO; }

where .LCO is compiler-generated symbol. And the latter does have
something to do with const folding, doesn't it?

-- 
Sergei.

Re: How to replace -O1 with corresponding -f's?

[Andrew Pinski]

On Jun 20, 2005, at 11:28 AM, Sergei Organov wrote:

> Andrew Pinski <pinskia@physics.uc.edu> writes:
>
>> On Jun 20, 2005, at 10:54 AM, Sergei Organov wrote:
>>
>>> so SYMBOL_FLAG_SMALL (flags 0x6 vs 0x2) is somehow being missed when 
>>> -O1
>>
>>> is turned on. Seems to be something at tree-to-RTX conversion time.
>>> Constant folding?
>>
>> No, it would mean that the target says that this is not a small data.
>> Also try it with the following code and you will see there is no 
>> difference:
>>
>>          double osvf() { return 314314314; }
>
> There is no difference in the sense that here both -O0 and -O1 behave
> roughly the same. So the problem is with detecting "smallness" for true
> constants by the target, right?

I think the bug is in rs6000_elf_in_small_data_p but since I have not
debuged it yet I don't know for sure.

Could you file a bug?  This is a target bug.

-- Pinski

Re: How to replace -O1 with corresponding -f's?

[Sergei Organov]

Andrew Pinski <pinskia@physics.uc.edu> writes:

> On Jun 20, 2005, at 11:28 AM, Sergei Organov wrote:
> 
> > Andrew Pinski <pinskia@physics.uc.edu> writes:
> >
> >> On Jun 20, 2005, at 10:54 AM, Sergei Organov wrote:
> >>
> >>> so SYMBOL_FLAG_SMALL (flags 0x6 vs 0x2) is somehow being missed when -O1
> 
> >>
> >>> is turned on. Seems to be something at tree-to-RTX conversion time.
> >>> Constant folding?
> >>
> >> No, it would mean that the target says that this is not a small data.
> >> Also try it with the following code and you will see there is no
> >> difference:
> 
> >>
> >>          double osvf() { return 314314314; }
> >
> > There is no difference in the sense that here both -O0 and -O1 behave
> > roughly the same. So the problem is with detecting "smallness" for true
> > constants by the target, right?
> 
> I think the bug is in rs6000_elf_in_small_data_p but since I have not
> debuged it yet I don't know for sure.
> 
> Could you file a bug?  This is a target bug.

Yeah, and I've reported it rather long ago against gcc-3.3 (PR 9571).
That time there were 3 problems reported in the PR of which only the
first one seems to be fixed (or are the rest just re-appeared in 4.0?).

I think PR 9571 is in fact regression with respect to 2.95.x despite the
[wrong] comments:

------- Additional Comment #5 From Franz Sirl  2003-06-17 15:31  [reply] -------

r0 is used as a pointer to sdata2, this is a bug, it should be r2. And
since only r2 is initialized in the ecrt*.o files, how can this work?
Besides that, even if you initialize r0 manually, it is practically
clobbered in about every function.
 

------- Additional Comment #6 From Mark Mitchell  2003-07-20 00:52  [reply] -------

Based on Franz's comments, this bug is not really a regression at all.
I've therefore removed the regression tags.

that I've tried to explain in my comment #7.

I don't think I need to file yet another PR in this situation, right?

-- 
Sergei.

Re: How to replace -O1 with corresponding -f's?

[Sergei Organov]

Andrew Pinski <pinskia@physics.uc.edu> writes:

> On Jun 20, 2005, at 11:28 AM, Sergei Organov wrote:
> 
> > Andrew Pinski <pinskia@physics.uc.edu> writes:
> >
> >> On Jun 20, 2005, at 10:54 AM, Sergei Organov wrote:
> >>
> >>> so SYMBOL_FLAG_SMALL (flags 0x6 vs 0x2) is somehow being missed when -O1
> 
> >>
> >>> is turned on. Seems to be something at tree-to-RTX conversion time.
> >>> Constant folding?
> >>
> >> No, it would mean that the target says that this is not a small data.
> >> Also try it with the following code and you will see there is no
> >> difference:
> 
> >>
> >>          double osvf() { return 314314314; }
> >
> > There is no difference in the sense that here both -O0 and -O1 behave
> > roughly the same. So the problem is with detecting "smallness" for true
> > constants by the target, right?
> 
> I think the bug is in rs6000_elf_in_small_data_p but since I have not
> debuged it yet I don't know for sure.

Well, provided that:

void
default_elf_select_rtx_section (enum machine_mode mode, rtx x,
				unsigned HOST_WIDE_INT align)
{
  /* ??? Handle small data here somehow.  */
  ...
}

is still there at varasm.c:5330, I don't think it's a target bug :(

-- 
Sergei.

Re: How to replace -O1 with corresponding -f's?

[Michael Meissner]

On Mon, Jun 20, 2005 at 07:57:17PM +0400, Sergei Organov wrote:
> Andrew Pinski <pinskia@physics.uc.edu> writes:
> 
> > On Jun 20, 2005, at 11:28 AM, Sergei Organov wrote:
> > 
> > > Andrew Pinski <pinskia@physics.uc.edu> writes:
> > >
> > >> On Jun 20, 2005, at 10:54 AM, Sergei Organov wrote:
> > >>
> > >>> so SYMBOL_FLAG_SMALL (flags 0x6 vs 0x2) is somehow being missed when -O1
> > 
> > >>
> > >>> is turned on. Seems to be something at tree-to-RTX conversion time.
> > >>> Constant folding?
> > >>
> > >> No, it would mean that the target says that this is not a small data.
> > >> Also try it with the following code and you will see there is no
> > >> difference:
> > 
> > >>
> > >>          double osvf() { return 314314314; }
> > >
> > > There is no difference in the sense that here both -O0 and -O1 behave
> > > roughly the same. So the problem is with detecting "smallness" for true
> > > constants by the target, right?
> > 
> > I think the bug is in rs6000_elf_in_small_data_p but since I have not
> > debuged it yet I don't know for sure.
> > 
> > Could you file a bug?  This is a target bug.
> 
> Yeah, and I've reported it rather long ago against gcc-3.3 (PR 9571).
> That time there were 3 problems reported in the PR of which only the
> first one seems to be fixed (or are the rest just re-appeared in 4.0?).
> 
> I think PR 9571 is in fact regression with respect to 2.95.x despite the
> [wrong] comments:
> 
> ------- Additional Comment #5 From Franz Sirl  2003-06-17 15:31  [reply] -------
> 
> r0 is used as a pointer to sdata2, this is a bug, it should be r2. And
> since only r2 is initialized in the ecrt*.o files, how can this work?
> Besides that, even if you initialize r0 manually, it is practically
> clobbered in about every function.

It's been a long time since I've hacked the PowerPC, but IIRC the instruction
set, a base register of '0' does not mean r0, but instead it means use 0 as the
base address.  Every place that uses a base register should use the register
class 'b' (BASE_REGS) instead of 'r' (GENERAL_REGS), which excludes r0 from
being considered.

Under the 32-bit eABI calling sequence, you have three small data areas:

The small data area that r2 points to (.sdata/.sbss).

The small data area that r13 points to (.sdata2/.sbss2).

The small data area centered around location 0 (ie, small positive addresses,
and the most negative addresses).  I don't recall that we had special sections
for this, since for many embedded apps, they couldn't allocate to those
addresses.

For these relocations, you should use R_PPC_EMB_SDA21, which the linker will
fill in both the offset and the appropriate base register into the instruction.

> ------- Additional Comment #6 From Mark Mitchell  2003-07-20 00:52  [reply] -------
> 
> Based on Franz's comments, this bug is not really a regression at all.
> I've therefore removed the regression tags.
> 
> that I've tried to explain in my comment #7.
> 
> I don't think I need to file yet another PR in this situation, right?
> 
> -- 
> Sergei.
> 

-- 
Michael Meissner
email: gnu@the-meissners.org
http://www.the-meissners.org

Re: How to replace -O1 with corresponding -f's?

[Sergei Organov]

Michael Meissner <gcc-mail@the-meissners.org> writes:

> On Mon, Jun 20, 2005 at 07:57:17PM +0400, Sergei Organov wrote:
> > Andrew Pinski <pinskia@physics.uc.edu> writes:
> > 
> > > On Jun 20, 2005, at 11:28 AM, Sergei Organov wrote:
> > > 
> > > > Andrew Pinski <pinskia@physics.uc.edu> writes:
> > > >
> > > >> On Jun 20, 2005, at 10:54 AM, Sergei Organov wrote:
> > > >>
> > > >>> so SYMBOL_FLAG_SMALL (flags 0x6 vs 0x2) is somehow being missed when -O1
> > > 
> > > >>
> > > >>> is turned on. Seems to be something at tree-to-RTX conversion time.
> > > >>> Constant folding?
> > > >>
> > > >> No, it would mean that the target says that this is not a small data.
> > > >> Also try it with the following code and you will see there is no
> > > >> difference:
> > > 
> > > >>
> > > >>          double osvf() { return 314314314; }
> > > >
> > > > There is no difference in the sense that here both -O0 and -O1 behave
> > > > roughly the same. So the problem is with detecting "smallness" for true
> > > > constants by the target, right?
> > > 
> > > I think the bug is in rs6000_elf_in_small_data_p but since I have not
> > > debuged it yet I don't know for sure.
> > > 
> > > Could you file a bug?  This is a target bug.
> > 
> > Yeah, and I've reported it rather long ago against gcc-3.3 (PR 9571).
> > That time there were 3 problems reported in the PR of which only the
> > first one seems to be fixed (or are the rest just re-appeared in 4.0?).
> > 
> > I think PR 9571 is in fact regression with respect to 2.95.x despite the
> > [wrong] comments:
> > 
> > ------- Additional Comment #5 From Franz Sirl  2003-06-17 15:31  [reply] -------
> > 
> > r0 is used as a pointer to sdata2, this is a bug, it should be r2. And
> > since only r2 is initialized in the ecrt*.o files, how can this work?
> > Besides that, even if you initialize r0 manually, it is practically
> > clobbered in about every function.
> 
> It's been a long time since I've hacked the PowerPC, but IIRC the instruction
> set, a base register of '0' does not mean r0, but instead it means use 0 as the
> base address.  Every place that uses a base register should use the register
> class 'b' (BASE_REGS) instead of 'r' (GENERAL_REGS), which excludes r0 from
> being considered.
> 
> Under the 32-bit eABI calling sequence, you have three small data areas:
> 
> The small data area that r2 points to (.sdata/.sbss).
> 
> The small data area that r13 points to (.sdata2/.sbss2).
> 
> The small data area centered around location 0 (ie, small positive
> addresses, and the most negative addresses). I don't recall that we
> had special sections for this, since for many embedded apps, they
> couldn't allocate to those addresses.
> 
> For these relocations, you should use R_PPC_EMB_SDA21, which the
> linker will fill in both the offset and the appropriate base register
> into the instruction.

Exactly, and that's what gcc actually and correctly does. My comment in
the PR exactly matches what you've said above:

 ------- Additional Comment #7 From Sergei Organov  2003-10-14 14:42  [reply] -------

 > r0 is used as a pointer to sdata2, this is a bug, it should be r2.

 No, the %r0 you see is fake. In the object file it's a special
 relocatable symbol that is resolved to either 2 (r2) or 13 (r13) by the
 linker depending on actual output section the symbol refers to, so
 there is no bug here.


IMHO, the assembly output is just somewhat misleading mentioning %r0 in
the place in question, -- it better should be just 0 I think as
SYM@sda21(0) would create less confusion than SYM@sda21(%r0).

On the other hand, I must admit the PR with item 1 (wrong section
attribute) fixed is not a regression anymore. I apologize, but I've
compared gcc-3.x/4.x with *patched* version of gcc-2.95.x that I've
hacked to force it to put double/float constants into .sdata2 section.
Now I've applied my hack to gcc-4.1.0 and get similar results, though
the patch is indeed a hack and is not satisfactory.

I think there is a fundamental problem that compiler-generated symbols
referring to constants are generated too late, at RTL level, and thus
aren't handled by the small section logic working on the tree level. Any
thoughts?

-- 
Sergei.

Re: How to replace -O1 with corresponding -f's?

[Zack Weinberg]

Sergei Organov wrote:
> Andrew Haley <aph@redhat.com> writes:
> 
> 
>>Sergei Organov writes:
>> > Hi,
>> > 
>> > Using gcc compiled from gcc-4_0-branch, in an attempt to see which
>> > particular optimization option makes my test case to be mis-optimized, I
>> > try to replace -O1 (which toggles on the problem) with corresponding set
>> > of -fxxx optimization options.
>>
>>In general you can't do this.  You can turn some optimization passes
>>off, though.
> 
> 
> Sigh :(

To be clear - there are a number of optimizations which have no corresponding
-f switch, being enabled or disabled solely by "if (optimize)" constructs; the
global 'optimize' flag is set by -On (n>0).  Similarly, there are places where
"if (optimize >= 2)" is the sole trigger.

This could be construed a bug, and I do not think there would be objection to
patches that add -f options for every such optimization.

zw

Re: How to replace -O1 with corresponding -f's?

[Sergei Organov]

Andrew Pinski <pinskia@physics.uc.edu> writes:

> On Jun 20, 2005, at 11:28 AM, Sergei Organov wrote:
> 
> > Andrew Pinski <pinskia@physics.uc.edu> writes:
> >
> >> On Jun 20, 2005, at 10:54 AM, Sergei Organov wrote:
> >>
> >>> so SYMBOL_FLAG_SMALL (flags 0x6 vs 0x2) is somehow being missed when -O1
> 
> >>
> >>> is turned on. Seems to be something at tree-to-RTX conversion time.
> >>> Constant folding?
> >>
> >> No, it would mean that the target says that this is not a small data.
> >> Also try it with the following code and you will see there is no difference:
> 
> >>
> >>          double osvf() { return 314314314; }
> >
> > There is no difference in the sense that here both -O0 and -O1 behave
> > roughly the same. So the problem is with detecting "smallness" for true
> > constants by the target, right?
> 
> I think the bug is in rs6000_elf_in_small_data_p but since I have not
> debuged it yet I don't know for sure.

No, the bug is not there as the function is never called for this
constant. The constant is generated in RTL and thus can't be passed
to this routine expecting tree.

The debugging shows that the constant in question first appears within
small_data_operand(op, mode) in the form:

op = (symbol_ref/u:SI (".LC0") [flags 0x2])
mode = DFmode

without the SYMBOL_FLAG_SMALL set resulting in returning 0 by the
routine.

We can naively try to add code at this point that checks
GET_MODE_SIZE(mode) and return 1 if the size is less than or equal to
the limit for sdata2 (=g_switch_value). However this attempt is not
satisfactory as later this same constant appears at the same place
as:

op = (symbol_ref/u:SI (".LC0") [flags 0x2])
mode = SImode(!)

Now, provided g_switch_value is set to 4 (it's default value is 8), we
would return 0 in the first case and 1 in the second case for the same
constant! The resulting assembly is weird.

The latter appearance of the constant with mode=SImode is due to call to
memory_address(DFMode, op) that calls force_reg(Pmode(=SImode), op)

#0  small_data_operand (op=0x401e2730, mode=SImode)
    at ../../../gcc/gcc/config/rs6000/rs6000.c:2358
#1  0x08704fb0 in rs6000_emit_move (dest=0x401e2740, source=0x401e2730, 
    mode=SImode) at ../../../gcc/gcc/config/rs6000/rs6000.c:3720
#2  0x0852cfb8 in gen_movsi (operand0=0x401e2740, operand1=0x401e2730)
    at ../../../gcc/gcc/config/rs6000/rs6000.md:7410
#3  0x08430c3c in emit_move_insn_1 (x=0x401e2740, y=0x401e2730)
    at ../../../gcc/gcc/expr.c:3086
#4  0x08431020 in emit_move_insn (x=0x401e2740, y=0x401e2730)
    at ../../../gcc/gcc/expr.c:3164
#5  0x08410891 in force_reg (mode=SImode, x=0x401e2730)
    at ../../../gcc/gcc/explow.c:607
#6  0x0841029b in memory_address (mode=DFmode, x=0x401e2730)
    at ../../../gcc/gcc/explow.c:409
....

At this stage I gave up trying to solve this puzzle. Any ideas how to
fix that?

-- 
Sergei.