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: Charles Baylis <charles dot baylis at linaro dot org>
- To: Richard Earnshaw <Richard dot Earnshaw at arm dot com>
- Cc: Maxim Kuvyrkov <maxim dot kuvyrkov at linaro dot org>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Ramana Radhakrishnan <Ramana dot Radhakrishnan at arm dot com>
- Date: Tue, 6 May 2014 17:05:16 +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>
Ping?
At this stage looking for general feedback on whether the define_split
approach in this patch is appropriate. If it is, I'll do a clean patch
for full review.
Archive link: http://gcc.gnu.org/ml/gcc-patches/2014-04/msg00078.html
On 2 April 2014 14:29, 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.
>
> Thanks
> Charles