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

[Sergei Organov <osv at topconrd dot ru>]

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.