[PATCH] Fix pr69012 ICE on building libgfortran for mips

[Richard Sandiford]

Bernd Edlinger <bernd.edlinger@hotmail.de> writes:
> Hi,
>
>
> the build of libgfortran and glibc for mips currently fails because we
> now evaluate mips_compute_frame_info more often than before.  If any
> instruction uses the predicate cprestore_save_slot_operand or
> cprestore_load_slot_operand the function mips_cprestore_address_p
> calls mips_get_cprestore_base_and_offset which needs valid data in
> frame->args_size and frame->hard_frame_pointer_offset, but these are
> initialized after calling mips_global_pointer, which makes the
> function get_attr_got raise an ICE.
>
> This patch re-orders the frame structure initialization, to initialize
> the required data before calling mips_global_pointer.
>
> I built a cross-glibc and cross fortran and c++ compiler and verified
> that the ICE is actually gone.

I think the problem is deeper than that though.  The instructions
that are triggering the ICE are only generated by the prologue,
so this means that we're trying to lay out the frame again after
the prologue has been generated, whereas it really needs to be
fixed by then.  (And even if recalculating it is a no-op, the
operation is still too expensive to be repeated lightly.)

Query functions like rtx_addr_can_trap_p(_1) shouldn't really be
changing or recalculating the frame layout or other global state.
I think we need to find a different way of getting the information.

Maybe reload/LRA should use its own structures to calculate the
range of "safe" stack and hfp offsets, then store them in crtl
for rtx_addr_can_trap_p to use.  AIUI, before reload, the only
non-trapping uses of sp should be for outgoing arguments, so we
can use a test based on the cumulative outgoing arguments size.
I don't think the hfp should be used at all before reload, so we
could conservatively return -1 for that case.

Thanks,
Richard