On 05/28/2015 03:50 PM, Eric Botcazou wrote:
Thanks very much. ChangeLog entry:
2015-05-14 James Bowman
* configure.ac: FT32 target added
* libgcc/config.host: FT32 target added
* gcc/config/ft32/: FT32 target added
* libgcc/config/ft32/: FT32 target added
> Thanks very much. ChangeLog entry:
>
> 2015-05-14 James Bowman
>
> * 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,
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 (i
> 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"), i
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, every
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?
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.)
On 05/14/2015 09:20 AM, James Bowman wrote:
On Thu, May 14, 2015 at 07:54:02AM -0500, Segher Boessenkool wrote:
I cannot reproduce this with your testcase. Please post the *exact*
testcase (nothing snipped) and the command line you used?
Making the array volatile and using optimisation help
On Thu, May 14, 2015 at 03:20:46PM +, James Bowman wrote:
> > It wants to reload pretty much everything. Looking at your code,
> > it seems you use the ancient interfaces instead of
> > TARGET_LEGITIMATE_ADDRESS_P, I don't think LRA works with that?
>
> The FT32 target uses TARGET_ADDR_SPACE_
> On Thu, May 14, 2015 at 07:54:02AM -0500, Segher Boessenkool wrote:
> > I cannot reproduce this with your testcase. Please post the *exact*
> > testcase (nothing snipped) and the command line you used?
>
> Making the array volatile and using optimisation helped. Kaboom.
>
> It wants to reloa
On Thu, May 14, 2015 at 07:54:02AM -0500, Segher Boessenkool wrote:
> I cannot reproduce this with your testcase. Please post the *exact*
> testcase (nothing snipped) and the command line you used?
Making the array volatile and using optimisation helped. Kaboom.
It wants to reload pretty much e
On Thu, May 14, 2015 at 01:44:48AM +, James Bowman wrote:
> > On Tue, May 12, 2015 at 10:17:01PM +, James Bowman wrote:
> > > It seems that with whenever a function's frame is bigger than 512 bytes,
> > > LRA loops.
I cannot reproduce this with your testcase. Please post the *exact*
testc
On Thu, May 14, 2015 at 01:44:48AM +, James Bowman wrote:
> > Compile with -da to get dump files, look at the .reload one (which is
> > for LRA if that is enabled), stare long and hard. I recommend coffee.
>
> OK! Looking more at this, the LRA is not actually looping on the link, but on
> an
> On Tue, May 12, 2015 at 10:17:01PM +, James Bowman wrote:
> > It seems that with whenever a function's frame is bigger than 512 bytes,
> > LRA loops. Likely this causes a problem because there is no actual
> > instruction for subtracting constants more than 512. However, there is a
> > "lin
On Tue, May 12, 2015 at 10:17:01PM +, James Bowman wrote:
> It seems that with whenever a function's frame is bigger than 512 bytes,
> LRA loops. Likely this causes a problem because there is no actual
> instruction for subtracting constants more than 512. However, there is a
> "link" pattern
On May 12, 2015, at 3:36 PM, Jeff Law wrote:
>
> It really depends on the complexity of getting LRA working for the target and
> given what I saw when looking at the port, I don't believe it should be much
> work.
LRA should default to on? Only preexisting ports about ask for, and get
non-LR
On 05/12/2015 04:17 PM, James Bowman wrote:
On 05/08/2015 06:04 PM, James Bowman wrote:
Are you using LRA or reload? The former is definitely preferred and for
a simple target like this, I'd expect the transition to be very easy.
I'm using reload. Attempting to naively switch on LRA resulte
> On 05/08/2015 06:04 PM, James Bowman wrote:
> >
> >> Are you using LRA or reload? The former is definitely preferred and for
> >> a simple target like this, I'd expect the transition to be very easy.
> >
> > I'm using reload. Attempting to naively switch on LRA resulted in
> >internal compil
On 05/08/2015 06:04 PM, James Bowman wrote:
Are you using LRA or reload? The former is definitely preferred and for
a simple target like this, I'd expect the transition to be very easy.
I'm using reload. Attempting to naively switch on LRA resulted in
internal compiler error: Max. number
On 03/19/2015 09:28 AM, James Bowman wrote:
Second ping.
Also, have attached updated patchset for the current gcc. Thanks.
Thanks. I don't see anything particularly worrisome from a correctness
standpoint. You may need to make minor updates to your .h file to cope
with some of Trevor's work a
Subject: RE: [PATCH, FT32] initial support
On Mon, 16 Feb 2015, James Bowman wrote:
> I have updated the target options. Space-saving is now enabled by
> -Os. There is also a new option -msim to enable building for the
> simulator (the simulator is pending submission to gdb-binuti
> On Mon, 16 Feb 2015, James Bowman wrote:
>
> > I have updated the target options. Space-saving is now enabled by
> > -Os. There is also a new option -msim to enable building for the
> > simulator (the simulator is pending submission to gdb-binutils).
>
> The documentation in this patch doesn't
: Tuesday, February 17, 2015 2:06 AM
To: James Bowman
Cc: gcc-patches@gcc.gnu.org
Subject: RE: [PATCH, FT32] initial support
On Mon, 16 Feb 2015, James Bowman wrote:
> I have updated the target options. Space-saving is now enabled by
> -Os. There is also a new option -msim to enable building f
On Mon, 16 Feb 2015, James Bowman wrote:
> I have updated the target options. Space-saving is now enabled by
> -Os. There is also a new option -msim to enable building for the
> simulator (the simulator is pending submission to gdb-binutils).
The documentation in this patch doesn't seem to have b
> From: Joseph Myers
> ...
> > +@table @gcctabopt
> > +
> > +@item -mspace
> > +@opindex mspace
> > +Enable code-size optimizations.
> > +Some of these optimizations incur a minor performance penalty.
>
> We already have -Os, so why is an architecture-specific option for this
> needed?
>
> > +A 1
On Wed, 11 Feb 2015, James Bowman wrote:
> > > +@table @gcctabopt
> > > +
> > > +@item -mspace
> > > +@opindex mspace
> > > +Enable code-size optimizations.
> > > +Some of these optimizations incur a minor performance penalty.
> >
> > We already have -Os, so why is an architecture-specific option
> > +@table @gcctabopt
> > +
> > +@item -mspace
> > +@opindex mspace
> > +Enable code-size optimizations.
> > +Some of these optimizations incur a minor performance penalty.
>
> We already have -Os, so why is an architecture-specific option for this
> needed?
Code compiled with -mspace is somewh
On Wed, 11 Feb 2015, James Bowman wrote:
> +@table @gcctabopt
> +
> +@item -mspace
> +@opindex mspace
> +Enable code-size optimizations.
> +Some of these optimizations incur a minor performance penalty.
We already have -Os, so why is an architecture-specific option for this
needed?
> +A 16-bit
(Thanks to everyone for the review. I have reworked the submission as
suggested. This does build cleanly with "--enable-werror-always")
FT32 is a new high performance 32-bit RISC core developed by FTDI for embedded
applications.
Support for FT32 has already been added to binutils. This patch ad
> optabs.c's expand_abs_nojump already knows this trick:
>
> /* If this machine has expensive jumps, we can do integer absolute
>value of X as (((signed) x >> (W-1)) ^ x) - ((signed) x >> (W-1)),
>where W is the width of MODE. */
>
> So if you define BRANCH_COST to be 2 or more ther
This patch is missing pieces such as Texinfo documentation (in
invoke.texi for target-specific options, at least) and config-list.mk
update so automatic builders verify that this target builds OK. See
"Back End" in sourcebuild.texi and make sure that you have everything
relevant.
It's a good idea
On 03/02/2015 07:05, Andrew Pinski wrote:
> Likewise of:
> +(define_insn "abssi2"
> + [(set (match_operand:SI 0 "register_operand" "=r")
> + (abs:SI (match_operand:SI 1 "register_operand" "r")))
> + (clobber (match_scratch:SI 2 "=&r"))]
> + ""
> + "ashr.l\t%2,%1,31\;xor.l\t%0,%1,%2\;sub.l\t%
On Mon, Feb 2, 2015 at 9:18 PM, James Bowman wrote:
> FT32 is a new high performance 32-bit RISC core developed by FTDI for
> embedded applications.
>
> Support for FT32 has already been added to binutils. This patch adds FT32
> support to gcc.
>
> Please can someone review it, and if appropriat
33 matches
Mail list logo
