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: [RS6000] Stack tie fix.


On Apr 5, 2012, at 16:03 , Alan Modra wrote:

> Well it turns out that gcc-4.4 still gets this testcase from pr30282
> wrong.

 Hmph :-(

>> There are lots of places in the emit_epilogue code that assign
>> frame_reg_rtx with different possible values, (hard_fp, sp, r11)
> 
> r12 too

 Right ... 

>> It is not at all obvious to me that the all places where we emit ties
>> have an accurate perception of what frame_reg's were possibly used before.
>> Is it clearer to you ?
> 
> I spent quite some time looking at it. ;)

 Oh, sure, that's why I'm asking :)

> Have you spotted an error
> somewhere, apart from spe_save_area_ptr not being mentioned in the
> stack tie?

 No, not really ... (more below)

> Hmm, I see I accidentally left out an assert from the stack tie
> patch.  This one may make you feel a little better.  :)
> 
>  /* Update stack and set back pointer unless this is V.4,
>     for which it was done previously.  */

>      /* If using some other frame reg previously, then we ought to
> 	 ensure it is mentioned in the stack tie emitted below.  */
>      gcc_checking_assert (REGNO (frame_reg_rtx) == 1
> 			   || REGNO (frame_reg_rtx) == 12);

 My concern (apart from possible remaining aliasing issues) was exactly
 what the comment above expresses, but right away I don't see how the assert
 does the check expressed by the comment, and there are other places where
 we emit ties.

 I need to review the function with your changes applied in greater detail.
 
 IIUC (please correct me if I'm wrong), every time we need to emit a tie, we
 must ensure that it references all the base regs that were used before to
 restore regs from the frame (to prevent the sp adjustment past the tie from
 moving prior to any of these accesses)
 
 Since we have several possible uses of different registers ahead, controlled
 by intricate conditions, I would have thought we'd need to maintain a list
 of these registers, to which we add every time we use a new one to access, and
 which we'd use to feed the tie references.

 If we don't do that, I still find it difficult to see that the ties alway do
 reference the proper set of regs (all those used to access the frame earlier).

 It might just be that there's part of the logic I still haven't grasped, so ...

>> FWIW, I had made an experiment at trying to extract subfunctions,
>> which might help such reasoning.

> I think this is worthwhile doing, but more important to try to make
> the logic simpler.
[...]

Entirely agreed! The exercise was just aimed at helping me understand
some of the logic :-)

Thanks a lot for your feedback, much appreciated,

Olivier


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