This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] [ARM] [RFC] Fix longstanding push_minipool_fix ICE (PR49423, lp1296601)
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Charles Baylis <charles dot baylis at linaro dot org>
- Cc: Ramana Radhakrishnan <Ramana dot Radhakrishnan at arm dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Maxim Kuvyrkov <maxim dot kuvyrkov at linaro dot org>
- Date: Mon, 30 Jun 2014 14:26:49 +0100
- Subject: Re: [PATCH] [ARM] [RFC] Fix longstanding push_minipool_fix ICE (PR49423, lp1296601)
- Authentication-results: sourceware.org; auth=none
- References: <CADnVucA0vOkQ6BdmCafh8pSoB0ZsQJJd=eaE2Bfkq2sSXVbpEQ at mail dot gmail dot com> <CAJA7tRbR+GJVgZOaKuC+MLx_jqM6_csYaP07Qr_PH0V1ge_sqA at mail dot gmail dot com> <CADnVucD8DMFm9NAKKiMzEirxhxoBCrYdCCjp=tkOtd+vvfTk9g at mail dot gmail dot com>
On 30/06/14 13:53, Charles Baylis wrote:
> On 18 June 2014 00:02, Ramana Radhakrishnan <ramana.gcc@googlemail.com> wrote:
>>
>> Interesting workaround but can we investigate further how to fix this
>> at the source rather than working around in the backend in this form.
>> It's still a kludge that we carry in the backend rather than fix the
>> problem at it's source. I'd rather try to fix the problem at the
>> source rather than working around this in the backend.
>
> I still think this is a back-end bug. Unless I've missed something, it
> looks like the compiler has generated an insn which meets its
> constraints (we'd see an "insn does not satisfy its constraints" ICE
> if not) but the back-end generates an ICE much later, when trying to
> emit code for it. The problem with trying to fix the bug "at source"
> in reload is that this inconsistency will remain as a potential latent
> bug.
>
> I see two options to fix it - one is to teach the back-end to
> successfully generate code for this insn, and the other is to teach
> the back-end that such an insn is not valid. My proposed patch does
> the former. The latter can presumably be achieved by providing a
> different kind of memory constraint which disallows constant pool
> references for these insns although I haven't tried this yet.
>
> Charles
>
I think we should be doing the latter (not permitting these operations).
If we wanted to do the former, we could just add an offset range for
the insn.
The reason we don't want the former is that the offset ranges are too
small and overly constrain literal pool placement.
R.