On Sun, Mar 21, 2010 at 3:43 AM, Jim Wilson 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 changed.
>> Both bel
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 Sun, Mar 21, 2010 at 2:47 AM, Jim Wilson 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 change in foor_
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 regis
On Sat, Mar 20, 2010 at 6:24 AM, Jim Wilson 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 insn “*mov_mode_i
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 c
On Fri, Mar 19, 2010 at 1:06 AM, fanqifei wrote:
> On Thu, Mar 18, 2010 at 2:30 AM, Jim Wilson 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_i
On Thu, Mar 18, 2010 at 2:30 AM, Jim Wilson 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 modified toolchain.
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 l
On Mon, Mar 15, 2010 at 5:24 AM, Jim Wilson 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 a10 0x0 a15;
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
12 matches
Mail list logo
