inc_for_reload improvement

["D.Venkatasubramanian, Noida" <dvenkat at noida dot hcltech dot com>]

Hi All,
 
While studying the code generation for SH Architecture, I
found that the code generated by inc_for_reload could be
improved. I am defining the problem below.

The function inc_for_reload in the file reload1.c
handles generation of code when post-increments
need to be reloaded. 
 
 Take for instance an instruction such as
         mov.l   r205+, r1
 
If the pseudo r205 could not get a hard register,
then following sequence of instructions is being
generated:
 
         mov.l   @(16,r14), r0
         add     #4, r0         <--- Increment the pseudo
         mov.l   r0, @(16,r14)  <--- Save it back
         add     #-4, r0        <--- Restore the value of the
                                pseudo, so that its value
                                could be used.
                                (This is a post-increment :-))
         mov.l   @r0+, r1
 
In this case, it would be perfectly legal to generate
code such as :
 
         mov.l   @(16,r14), r0
         mov.l   @r0+, r1
         mov.l   r0, @(16,r14)
  
inc_for_reload is not doing so probably because problems
would crop up, if instead we had an instruction which
changed control flow, such as a jump instruction:
 
         jmp     r205+
 
 If we change this to :
 
         mov.l   @(16,r14), r0
         jmp     @r0+
         mov.l   r0, @(16,r14)
 
then it may not be correct.
 
 At present, inc_for_reload has this code :
 
 /* If couldn't do the increment directly, must increment in RELOADREG.
    The way we do this depends on whether this is pre- or
post-increment.
    For pre-increment, copy INCLOC to the reload register, increment it
    there, then save back.  */
 
 if (! post)
   {
     if (in != reloadreg)
       emit_insn (gen_move_insn (reloadreg, real_in));
       emit_insn (gen_add2_insn (reloadreg, inc));
       store = emit_insn (gen_move_insn (incloc, reloadreg));
   }
 else
   {
     /* Postincrement.
        Because this might be a jump insn or a compare, and because
 RELOADREG
        may not be available after the insn in an input reload, we must
 do
        the incrementation before the insn being reloaded for.
 
        We have already copied IN to RELOADREG.  Increment the copy in
        RELOADREG, save that back, then decrement RELOADREG so it has
        the original value.  */
     emit_insn (gen_add2_insn (reloadreg, inc));                    <---
     store = emit_insn (gen_move_insn (incloc, reloadreg));         <---
     emit_insn (gen_add2_insn (reloadreg, GEN_INT (-inc_amount)));  <---
   }
 

  The code could be changed to something like :
 
   if (GET_CODE (value) == JUMP_INSN)
     {
       emit_insn (gen_add2_insn (reloadreg, inc));                  <---
       store = emit_insn (gen_move_insn (incloc, reloadreg));       <---
       emit_insn (gen_add2_insn (reloadreg, GEN_INT (-inc_amount)));<---
     }
   else
     {
       store = gen_move_insn (incloc, reloadreg);                   <---
     }
 
In case, where we do not have a jump instruction, 
we are preserving the store rtx so that it can be
emitted at an appropriate position, i-e- after the
emission of the next instruction in the sequence.
 
I am investigating how to specify the point where
this preserved insn should be emitted. That is, after
the next instruction in the sequence is emitted.
It may require some tweaking of the reload1.c code,
especially in the emit_input_reload_insns function
where the inc_for_reload function is called.
 
As I am not familiar with the source of reload1.c,
could someone guide me where I should specify the
emission of the preserved insn, in the source. I
also tried emit_insn_later in the store statement
but without success.
 
IMHO, we may only have to check for JUMP_INSN because,
any compare instruction which could change control
flow will be of this class also. Insns, where only
comparison takes place will not affect the new sequence
adversely.

Could someone give some pointers on how I could implement
the solution.
 
Thanks and Best Regards,
 
Venky