> Doesn't the frame have to be laid out correctly during the final reload
> subpass anyway, in order to get the right elimination choices and
> elimination offsets?  If so, I'm not sure what the " &&
> info->reload_completed" check in rs6000_stack_info achieves.  It seems like
> that's at least partly responsible for the problem.

Clearly a comment would be in order.  I'm not sure it's responsible for the 
problem, unless you mean that it's papering over the underlying issue, in 
which case you're probably right.  This underlying issue is probably that:

  /* Calculate which registers need to be saved & save area size.  */
  info->first_gp_reg_save = first_reg_to_save ();

overlooks the specific status of the frame pointer, i.e. it doesn't test 
frame_pointer_needed explicitly, which I think is pretty much mandatory.
The rest of the code apparently works correctly despite this though.

> I realise you've already applied it and that you saw it as a hack too,
> but this seems like a bit too much.  IMO a cleaner fix would be to define
> TARGET_COMPUTE_FRAME_LAYOUT for rs6000.

Well, it's a hack on top of a big kludge (the get_initial_register_offset 
stuff in rtlanal.c) so it can be viewed as a safety net too. :-)

> I guess that approach means that TARGET_COMPUTE_FRAME_LAYOUT isn't really
> optional though.

IMO another workaround for the underlying issue.

-- 
Eric Botcazou

Reply via email to