On 05.01.2016 21:41, Richard Sandiford wrote:
> Matthew Fortune writes:
>> Bernd Edlinger writes:
>>> Yes, I agree, it _should_ be a no-op, but given the complexity of
>>> mips_compute_frame_info it is probably better to use cached values after
>>> reload completed.
>>>
>>> Before reload_complete
Matthew Fortune writes:
> Bernd Edlinger writes:
>> On 30.12.2015 15:31, Richard Sandiford wrote:
>> > 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 ag
Bernd Edlinger writes:
> Hi,
>
> On 30.12.2015 15:31, Richard Sandiford wrote:
> > 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
Hi,
On 30.12.2015 15:31, Richard Sandiford wrote:
> 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
Bernd Edlinger 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
