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 <[EMAIL PROTECTED]> wrote:
"Rohit Arul Raj" <[EMAIL PROTECTED]> 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
