On 05/28/2015 03:50 PM, Eric Botcazou wrote:
Thanks very much. ChangeLog entry:
2015-05-14 James Bowman james.bow...@ftdichip.com
* configure.ac: FT32 target added
* libgcc/config.host: FT32 target added
* gcc/config/ft32/: FT32 target added
*
Thanks very much. ChangeLog entry:
2015-05-14 James Bowman james.bow...@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
*
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*
testcase
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
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
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
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 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
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
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
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,
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
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
link pattern
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
On May 12, 2015, at 3:36 PM, Jeff Law l...@redhat.com 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
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.
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 that
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
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-binutils).
The documentation
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
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
: 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
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 16-bit signed
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 signed
+@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 somewhat slower than
(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
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 there should
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%0,%0,%2)
optabs.c's
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
31 matches
Mail list logo
