This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH, FT32] initial support
- From: Segher Boessenkool <segher at kernel dot crashing dot org>
- To: Jeff Law <law at redhat dot com>
- Cc: James Bowman <james dot bowman at ftdichip dot com>, Joseph Myers <joseph at codesourcery dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 14 May 2015 14:24:54 -0500
- Subject: Re: [PATCH, FT32] initial support
- Authentication-results: sourceware.org; auth=none
- References: <55511270 dot 70708 at redhat dot com> <CA9BBF0458F83C4F9051448B941B57D117B9D21F at glaexch3> <CA9BBF0458F83C4F9051448B941B57D117BA023B at glaexch3> <20150514173612 dot GB26719 at gate dot crashing dot org> <5554EA0C dot 6040309 at redhat dot com>
On Thu, May 14, 2015 at 12:31:40PM -0600, Jeff Law wrote:
> On 05/14/2015 11:36 AM, Segher Boessenkool wrote:
> >The alternative that allows move to mem is alt 1, but it thinks the operand
> >doesn't match (it is "B" or "W"), it picks alt 0, loop, everyone unhappy.
> >
> >"B" should match it seems?
> >
> >(Why does IRA think r56 should be in memory? Yeah, good question.)
> Independent of that, if a reg-reg move generated by LRA (which is really
> a mem->reg or reg->mem) blows up on this target for some reason, then
> that needs to be addressed independently of whether or not IRA might
> have made a bad choice for which pseudo to spill.
Yes. It probably is because of the "volatile" I inserted for it
to fail at all, anyway.
Changing constraints ABWef to be define_memory_constraint (instead of
define_constraint) makes this testcase pass. It also makes the build
pass (it failed before; 90 reloads in libgcc).
Pretty miserable code for those memory accesses, but hey, better
than an ICE ;-)
Segher