Abt RTL expression - Optimization
Rohit Arul Raj
rohitarulraj@gmail.com
Mon Oct 30 09:39:00 GMT 2006
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
>
More information about the Gcc
mailing list