[PATCH, FT32] initial support

Jeff Law law@redhat.com
Fri May 15 06:41:00 GMT 2015


On 05/14/2015 06:43 PM, James Bowman wrote:
>> On 05/14/2015 01:24 PM, Segher Boessenkool wrote:
>>> 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 ;-)
>> Makes sense if it wasn't defined as a memory constraint that LRA would
>> be having trouble -- odds are reload would have barf'd at some point too.
>>
>> The only difference is I'm actually still better at understanding what
>> reload's doing from its dumps than LRA.  It's hard to throw away decades
>> of retained knowledge earned the hard way.
>>
>> James, can you go ahead and make that change to ABWef and enable LRA and
>> commit your changes to the trunk?
>
> OK, ABWef changes made, and fixed a couple of pattern holes that they exposed.
> Added a new target option "-mlra" to enable LRA.  Updated invoking.texi.
>
> Please can someone commit this, if appropriate, as I do not have write access to the tree.
>
> Thanks very much. ChangeLog entry:
>
> 2015-05-14  James Bowman  <james.bowman@ftdichip.com>
>
>          * configure.ac: FT32 target added
>          * libgcc/config.host: FT32 target added
>          * gcc/config/ft32/: FT32 target added
>          * libgcc/config/ft32/: FT32 target added
>          * gcc/doc/install.texi, invoke.texi, md.texi: FT32 details added
>          * gcc/doc/contrib.texi: self added
>          * contrib/config-list.mk: FT32 target added
>          * configure: Regenerated
Well, the plan will be for you to maintain the port.  So you should go 
ahead and get write access so that you can commit changes to the port.


See authenticated access on this page

https://gcc.gnu.org/svnwrite.html

List me as your sponsor

Thanks for your patience,
Jeff



More information about the Gcc-patches mailing list