On Sun, Mar 21, 2010 at 3:43 AM, Jim Wilson wil...@codesourcery.com wrote:
On Sun, 2010-03-21 at 03:40 +0800, fanqifei wrote:
foor_expand_move is changed and it works now.
However, I still don't understand why there was no such error if below
condition was used and foor_expand_move was not
On Sat, Mar 20, 2010 at 6:24 AM, Jim Wilson wil...@codesourcery.com wrote:
On Fri, 2010-03-19 at 22:06 +0800, fanqifei wrote:
1. I add movsi expander in which function foor_expand_move is used to
force the operands[1] to reg and emit the move insn.
Another change is that in the define of
On Sat, 2010-03-20 at 14:29 +0800, fanqifei wrote:
I changed the condition in *mov_insn_mode to below:
(register_operand(operands[0], SImode) ||
register_operand(operands[1],SImode))
I think you need the same change in foor_expand_move. I.e., if neither
the source or dest is a register,
On Sun, Mar 21, 2010 at 2:47 AM, Jim Wilson wil...@codesourcery.com wrote:
On Sat, 2010-03-20 at 14:29 +0800, fanqifei wrote:
I changed the condition in *mov_insn_mode to below:
(register_operand(operands[0], SImode) ||
register_operand(operands[1],SImode))
I think you need the same
On Sun, 2010-03-21 at 03:40 +0800, fanqifei wrote:
foor_expand_move is changed and it works now.
However, I still don't understand why there was no such error if below
condition was used and foor_expand_move was not changed.
Both below condition and (register_operand(operands[0], SImode) ||
On Fri, 2010-03-19 at 22:06 +0800, fanqifei wrote:
1. I add movsi expander in which function foor_expand_move is used to
force the operands[1] to reg and emit the move insn.
Another change is that in the define of insn “*mov_mode_insn in which
a condition is added to prevent a store const
On Thu, Mar 18, 2010 at 2:30 AM, Jim Wilson wil...@codesourcery.com wrote:
On Wed, 2010-03-17 at 11:27 +0800, fanqifei wrote:
You are correct. The reload pass emitted the clr.w insn.
However, I can see loop opt passes after reload:
problem1.c.174r.loop2_invariant1
Not unless you have a
On Wed, 2010-03-17 at 11:27 +0800, fanqifei wrote:
You are correct. The reload pass emitted the clr.w insn.
However, I can see loop opt passes after reload:
problem1.c.174r.loop2_invariant1
Not unless you have a modified toolchain. We don't run loop opt after
register allocation. See the
On Mon, Mar 15, 2010 at 5:24 AM, Jim Wilson wil...@codesourcery.com wrote:
On 03/10/2010 10:48 PM, fanqifei wrote:
For below piece of code, the instruction clr.w a15 obviously doesn't
belong to the inner loop.
6: bd f4 clr.w a15; #clear to zero
8: 80 af 00 std.w
On 03/10/2010 10:48 PM, fanqifei wrote:
For below piece of code, the instruction clr.w a15 obviously doesn't
belong to the inner loop.
6: bd f4clr.w a15; #clear to zero
8: 80 af 00std.w a10 0x0 a15;
There is info lacking here. Did you compile with optimization?
I am porting gcc 4.3.2 to my own micro-controller.
For below piece of code, the instruction clr.w a15 obviously doesn't
belong to the inner loop. Compiler should be smart enough to move it
to the beginning of the function.
How I can hoist the constant out of loops?
Maybe the costs functions have
11 matches
Mail list logo
