Re: Abt RTL expression - Optimization

["Rohit Arul Raj" <rohitarulraj at gmail dot com>]

Hi all,

The problem due to which the below mentioned program was not working
is because of CODE HOISTING pass. I just masked the code hoisting step
and the program worked fine.

1. The instruction no's 11, 12, 13 are removed when -Os optimization
is enabled (it considers n, h as dead). Is there any way to emit RTL
Instruction such that it can be neglected by Code Hoisting pass.

; Start of basic block 0, registers live: (nil)
(note 9 6 11 0 [bb 0] NOTE_INSN_BASIC_BLOCK)

(insn 11 9 12 0 (parallel [
           (set (reg/f:SI 28)
               (symbol_ref:SI ("n") [flags 0x2] <var_decl 0x40227160 n>))
           (clobber (reg:CC 21 cc))
       ]) 22 {movsi_long_const} (nil)
   (nil))

(insn 12 11 13 0 (set (reg:SI 29 [ n ])
       (mem/c/i:SI (reg/f:SI 28) [2 n+0 S4 A32])) 15 {movsi_load} (nil)
   (expr_list:REG_EQUAL (mem/c/i:SI (symbol_ref:SI ("n") [flags 0x2]
<var_decl 0x40227160 n>) [2 n+0 S4 A32])
       (nil)))

(insn 13 12 50 0 (set (reg:CC 21 cc)
       (compare:CC (reg:SI 29 [ n ])
           (const_int 30 [0x1e]))) 68 {*cmpsi_internal} (nil)
   (nil))

2. Any documentation on Code Hoisting Algorithm used by GCC 4.1.1?


Regards,
Rohit

On 26 Oct 2006 22:30:43 -0700, Ian Lance Taylor <iant@google.com> wrote:
> "Rohit Arul Raj" <rohitarulraj@gmail.com> writes:
>
> > > > This small bit of code worked fine with all optimization except Os.

           unsigned int p;
> > > > unsigned int n = 30;
> > > > void x ()
> > > > {
> > > >  unsigned int h;
> > > >  h = n <= 30;           // Line 1
> > > >  if (h)
> > > >    p = 1;
> > > >  else
> > > >    p = 0;
> > > > }
> > > >
> > > > when we tried to debug the emitted RTL instruction for Os, it was
> > > > found that RTL instruction for Line #1 (Compare and gtu) were not at
> > > > all emitted. i.e. there is no reference with respect to "h or n". For
> > > > the same optimization Os, if we declare the identifier "h" as global,
> > > > it generates the instructions properly.
> > >
> > > That small bit of code won't compile, since 'p' is undeclared.  If 'p'
> > > is a global variable, then this certainly seems to be a bug.  But you
> > > should be aware that -Os changes inlining behaviour, and different
> > > inlining may cause different behaviour here depending on how 'p' is
> > > used.
> >
> > p is a global variable. But the problem is not with p, but with
> > codegeneration for h, n.
>
> Sure.  But the most likely reason that the test of 'h' is being
> removed is that the compiler thinks that there is no need to store to
> 'p'.  And once the test of 'h' is removed, there is no need to test
> 'n'.
>
> > In the RTL dump after cse2 pass, i do have the code for h, n. But in
> > the RTL dump after life analysis, that part of code is missing.
> > Is this output of cse2 pass used for life analysis?
>
> If I understand the question correctly, then the answer is yes.  The
> compiler works by creating an intermediate representation (IR) and
> then manipulating it.  The cse2 pass runs on the IR, then the life1
> pass runs on the IR.  The .cse2 file contains a dump of the IR after
> the cse2 pass is complete.
>
>
> > > > 3. What are the probable causes for the elimination of RTL code's
> > > > (Compare & gtu) between the above mentioned passes?
> > >
> > > The probable cause is that 'p' appears to be unused, and the
> > > assignment to 'p' is dead.
> > >
> > since p is a global variable, it can be used in other functions. Any
> > other causes?
>
> I can't think of any.
>
>
> > 4. If i disable gcse optimization pass, (i.e. -Os -fno-gcse), the code
> > is generated properly for h , n and the program works fine (it failed
> > for -Os). How does gcse affect code generation at .life1 pass.
>
> The gcse pass can change the IR significantly, and thus affects the
> life1 pass in many different ways which are difficult to characterize.
>
> You really have to look at what exactly is going on.
>
> ian