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
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
On Tue, May 10, 2011 at 6:23 PM, Richard Guenther
richard.guent...@gmail.com wrote:
On Tue, May 10, 2011 at 12:08 PM, fanqifei fanqi...@gmail.com 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
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?
I am not
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 “k32” in which k is 64bits integer, the
“define_expand” should fail because op2 is 32, not 1.
However, I can see the
wrote:
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 “k32” in which k is 64bits integer, the
“define_expand” should fail because op2 is 32
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
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
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 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
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
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
2010/1/27 fanqifei fanqi...@gmail.com:
2010/1/25 Ulrich Weigand uweig...@de.ibm.com:
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
2010/1/18 Adam Nemet adambne...@gmail.com:
fanqifei fanqi...@gmail.com 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 uweig...@de.ibm.com:
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
2010/1/16 fanqifei fanqi...@gmail.com:
2010/1/15 Ian Lance Taylor i...@google.com:
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
2010/1/18 Adam Nemet adambne...@gmail.com:
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
2010/1/15 Ian Lance Taylor i...@google.com:
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
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])
2010/1/13 Bingfeng Mei b...@broadcom.com:
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= (x0xFF00) | ((i16)0x00FF);
is exactly what insv can do.
I all tried
2010/1/13 Bingfeng Mei b...@broadcom.com:
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
{
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
23 matches
Mail list logo
