This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Fix problem with late insns in sibcall


    Can you please at least include your analysis of the problem
    in all of these cases?  Without that, someone reviewing the
    change has to start from scratch.

In this case, I was having trouble understanding the analysis log and I'm
not totally sure what applies to what since there were two separate problems,
one of which I think was HP PA-specific in this same bug report, but what
I see is:

 For -O2 -gnatp, the .02.eh RTL sequence for the second call to the nested
 shift in my_curtain.shift reads like:
 
 
 (insn 34 32 36 (set (reg:SI 96)
         (mem/s/j:SI (plus:SI (reg/v/f:SI 94)
                 (const_int 4 [0x4])) [5 <variable>.y+0 S4 A32])) -1 (nil)
     (nil))
 :
 ...
 :
 (insn 38 36 39 (set (reg:SI 26 %r26)
         (reg:SI 96)) -1 (nil)
     (nil))
 :
 ^^^^^^^^^^^^^^^^
 Set arg (r26) to the value of My_Prof.Y
 
 
 (call_insn/u/j 39 38 40 (parallel[
     (set (reg:SI 28 %r28)
          (call (mem:SI (symbol_ref/v:SI ("@my_curtain__shift__shift___0")))
                     (const_int 16 [0x10])))
             (clobber (reg:SI 0 %r0))
             (use (reg:SI 2 %r2))
             (use (const_int 0 [0x0]))
         ] ) -1 (nil)
     (nil)
     (expr_list (use (reg:SI 26 %r26))
         (expr_list (use (reg:SI 29 %r29))
             (nil))))
 :
 ^^^^^^^^^^^^^^^^^^^^^^^^^^
 Perform the call, storing the updated value in r28.
 
 (barrier 40 39 42)
 ^^^^^^^^^^^^^^^^^^^
 Err, this is an indication that the flow cannot fallthru after the
 call, despite the following insn which stores the result back into
 the parameter to "shift", passed by reference:
 
 (insn 42 40 57 (set (mem/s/j:SI (plus:SI (reg/v/f:SI 94)
                 (const_int 4 [0x4])) [5 <variable>.y+0 S4 A32])
         (reg:SI 28 %r28)) -1 (nil)
     (nil))
 
 This insn then disapears from the following dumps, presumably because
 considered dead after the barrier. There is no such barrier after the first
 call.

The confusing part to me is that after this discussion, the fix for the
3.2-based GNAT was to disable sibcall for PA due to a known bug (fixed
for 3.3).  Then this showed up on another target.

Olivier, can you explain more?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]