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: Ramana Radhakrishnan <ramana dot gcc at googlemail dot com>
- To: Charles Baylis <charles dot baylis at linaro dot org>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, Richard Earnshaw <Richard dot Earnshaw at arm dot com>, Ramana Radhakrishnan <Ramana dot Radhakrishnan at arm dot com>, Maxim Kuvyrkov <maxim dot kuvyrkov at linaro dot org>
- Date: Wed, 18 Jun 2014 00:02:51 +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>
- Reply-to: ramrad01 at arm dot com
On Wed, Apr 2, 2014 at 2:29 PM, Charles Baylis
<charles.baylis@linaro.org> wrote:
> Hi
>
> This patch fixes the push_minipool_fix ICE, which occurs when the ARM
> backend encounters a zero/sign extending load from a constant pool.
>
> I don't have a current test case for trunk, lp1296601 has a test case
> which affects the linaro-4.8 branch. As far as I know, there has been
> no fix for this on trunk.
>
> The approach taken in this patch is to extend each pattern where this
> can occur, so that it triggers a define_split to synthesise a
> constant move instead. Some but not all extend patterns have
> previously added pool_range attributes to work-around this problem,
> this patch removes those, and also fixes the remaining patterns. Some
> patterns have slightly more complex workarounds, which I have not yet
> analysed, but it seems worth posting the patch at this stage to get
> feedback on the general approach.
>
> Tested on arm-unknown-linux-gnueabihf (qemu), bootstrap in progress.
>
> If this looks good, I'll clean it up for a more detailed review.
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.
Ramana
>
> Thanks
> Charles