I am using gcc4.3.2.
In our microcontroller, move instruction(mov reg, imm) can accept
16bits and 32bits immediate operand.
The data memory size is less than 64KB, however, code memory size is
larger than 64KB.
The immediate operand may be addresses of variables in data sections
and function pointe
>> Which file or fucntion should I look into? Maybe I can work around in 4.3.2
>
> Look into tree-ssa-alias.c and tree-ssa-structalias.c
>
>> What change in 4.5 fixed it?
>
> A complete rewrite of the above ...
>
> Richard.
So is there easy way to work around in 4.3.2 to disable the randomization?
On Tue, May 10, 2011 at 6:23 PM, Richard Guenther
wrote:
> On Tue, May 10, 2011 at 12:08 PM, fanqifei wrote:
>> Hi all,
>>
>> I am poring gcc 4.3.2 for a micro-controller and use it to compile C
>> source code.
>> I found that gcc is very sensitive to small ch
Hi all,
I am poring gcc 4.3.2 for a micro-controller and use it to compile C
source code.
I found that gcc is very sensitive to small changes in C source code
even if the change doesn't affect any function of the source code.
For example, a source file foo.c includes a header file foo.h.
If one ma
ote:
> fanqifei schrieb:
>> Hi all,
>>
>> I am porting gcc to a microprocessor. There are no 64bits instructions
>> in it. I added a small logical shift right optimization to the md
>> file(see below).
>> For the statement “k>>32” in which k is 64bits integer, the
Hi all,
I am porting gcc to a microprocessor. There are no 64bits instructions
in it. I added a small logical shift right optimization to the md
file(see below).
For the statement “k>>32” in which k is 64bits integer, the
“define_expand” should fail because op2 is 32, not 1.
However, I can see the
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_mov
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))
>
>
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
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 a
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 yo
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
&g
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
According to the internal manual, insn length attribute can be used to
to calculate the length of emitted code chunks when verifying branch
distances.
Can it be used in code size optimization?
I may change TARGET_RTX_COSTS in my gcc port and return costs
regarding the ins lengths. I can see code s
2010/1/27 fanqifei :
> 2010/1/25 Ulrich Weigand :
>> Qifei Fan wrote:
>>
>>> > But insn#479 is not recognized by recog() in insn-recog.c and the
>>> > compilation failed. (recog only recognizes RTL defined in md, right?)
>>> > Here the b
2010/1/18 Adam Nemet :
> fanqifei writes:
>> Paolo Bonzini said that insv instruction might be synthesized
>> later by combine. But combine only works on at most 3 instructions and
>> insv is not generated in such case.
>> So exactly when will the insv pattern
2010/1/25 Ulrich Weigand :
> Qifei Fan wrote:
>
>> > But insn#479 is not recognized by recog() in insn-recog.c and the
>> > compilation failed. (recog only recognizes RTL defined in md, right?)
>> > Here the backtrace is
>> > reload--->cleanup_subreg_operands--->extract_insn_cached--->extract_insn-
2010/1/16 fanqifei :
> 2010/1/15 Ian Lance Taylor :
>> There are many places where that insn could be generated, so it's
>> pretty hard to answer your question as asked.
>>
>> I recommend setting a breakpoint on make_insn_raw if
>> cfun->emit->x_cur_insn
2010/1/18 Adam Nemet :
> Sorry for jumping in late. See make_file_assigment in combine.c.
>
> The problem usually is that:
>
> (set A (ior (and B C1) OTHER))
>
> can only be turned into a bit-insertion if A and B happen to be the same
> pseudos.
>
> Adam
>
Thank you, Adam. The problem is that be
2010/1/15 Ian Lance Taylor :
> There are many places where that insn could be generated, so it's
> pretty hard to answer your question as asked.
>
> I recommend setting a breakpoint on make_insn_raw if
> cfun->emit->x_cur_insn_uid == 479. Then a backtrace will show you
> what is creating the insn.
2010/1/13 fanqifei :
> Hi,
> I am working on a micro controller and trying to port gcc(4.3.2) for it.
> Not the compiling process runs into the following error:
> a.c: In function 'task':
> a.c:150: error: unrecognizable insn:
> (insn 479 478 320 19 a:381 (set (reg:S
2010/1/13 Bingfeng Mei :
> OOPs, I don't know that. Anyway, I won't count on GCC to
> reliably pick up these complex patterns. In our port, we
> implemented clz/ffs/etc as intrinsics though they are present as
> standard patterns.
>
> Bingfeng
Could you please show me the path of the source code t
2010/1/13 Bingfeng Mei :
> Your instruction is likely too specific to be picked up by GCC.
> You may use an intrinisc for it.
>
> Bingfeng
but insv is a standard pattern name.
the semantics of expression x= (x&0xFF00) | ((i<<16)&0x00FF);
is exactly what insv can do.
I all tried mips gcc cr
Hi,
I am working on a micro controller and trying to port gcc(4.3.2) for it.
Not the compiling process runs into the following error:
a.c: In function 'task':
a.c:150: error: unrecognizable insn:
(insn 479 478 320 19 a:381 (set (reg:SI 12 a12)
(plus:SI (mult:SI (reg:SI 9 a9 [204])
this?
struct test_foo {
unsigned int a:18;
unsigned int b:2;
unsigned int c:12;
};
struct test_foo x;
unsigned int foo()
{
unsigned int a=x.b;
x.b=2;
return a;
}
Thanks!
fanqifei
25 matches
Mail list logo
