Functional Specification for GCC port
hi, What might be functional specifications for a GCC porting project.Output format and ABI might be included in functional specification. For writing a compiler from scratch ,funcional specifications are quite clear ,but for porting GCC what should be included in funcional specification document and same is the case for design document
AMD dual core opetron optimization
hi,
I'm doing trying to write some optimized code for AMD dual core
opetron processor.But things are getting no where.I've installed
Fedora 5 with 2.6 series Linux kernel and 4 series GCC
Following are few lines of code which are consuming close to 100
cycles.Yes this is not the forum for such questions but i think people
on linux kernel and GCC are best to answer such type of questions.I'm
realy getting frustated and helpless ,that's why i've put question on
this forum.
/***/
/* these variables will be used for RDTSC instrucion */
uint64_t before, overhead, clocks;
/*ReadTsc funtion is given below */
before=ReadTsc();
before=ReadTsc();
before=ReadTsc();
overhead=ReadTsc()-before;
printf(" ReadTSC overerhead is %lu ",overhead);
unsigned int test;
unsigned long buffer [128];
buffer[12]=08;
buffer[13]=00;
buffer[23]=06;
/* starting cycles */
before=ReadTsc();
/**Start of Targeted code
**/
test= buffer[12] | buffer[13] | buffer[23] ;
switch( test )
{
case 12:
asm(" jmp proc_1");
case 13:
asm("jmp proc_2");
case 14:
asm("jmp proc_3");
case 15:
asm("jmp proc_4");
default :
asm("jmp proc_5");
}
asm(" proc_5:");
/**End of Targeted code **/
/*current cycles */
clocks=ReadTsc() ;
clocks=clocks - before;
printf("\n cycles consumed %lu \n",clocks - overhead);
/**/
The overhead varies from generally 360 to 395 cycles .Sometimes it
also reduces close to 270 cycles.
Cycles consumed by the targetd code varies from 20 to 100
cycles.Theoratically i thing cycles consumed should be less than
20.Then why so many cycles ? and the output vary from 20 to 100
cycles .Sometimes it crosses 100 cycles as well.
Sometimes the cycles consumed by targetted code become far less that
the RDTSC instrucion overhead.
Is there better way to write above code.I even used the prefetch
instruction before the targeted code to make sure that buffer is in
the L1 cache but no success.
The code for ReadTsc() is as follows.Please also tell me if its
correct way to measure cycles .
/*/
typedef long long __int64;
__int64 ReadTSC() {
int res[2]; // store 64 bit result here
#if defined(__GNUC__) && !defined(__INTEL_COMPILER)
// Inline assembly in AT&T syntax
#if defined (_LP64) // 64 bit mode
__asm__ __volatile__ ( // serialize (save rbx)
"xorl %%eax,%%eax \n push %%rbx \n cpuid \n"
::: "%rax", "%rcx", "%rdx");
__asm__ __volatile__ ( // read TSC, store edx:eax in res
"rdtsc\n"
: "=a" (res[0]), "=d" (res[1]) );
__asm__ __volatile__ ( // serialize again
"xorl %%eax,%%eax \n cpuid \n pop %%rbx \n"
::: "%rax", "%rcx", "%rdx");
#else// 32 bit mode
__asm__ __volatile__ ( // serialize (save ebx)
"xorl %%eax,%%eax \n pushl %%ebx \n cpuid \n"
::: "%eax", "%ecx", "%edx");
__asm__ __volatile__ ( // read TSC, store edx:eax in res
"rdtsc\n"
: "=a" (res[0]), "=d" (res[1]) );
__asm__ __volatile__ ( // serialize again
"xorl %%eax,%%eax \n cpuid \n popl %%ebx \n"
::: "%eax", "%ecx", "%edx");
#endif
#else
// Inline assembly in MASM syntax
__asm {
xor eax, eax
cpuid // serialize
rdtsc // read TSC
mov dword ptr res, eax // store low dword in res[0]
mov dword ptr res+4, edx // store high dword in res[1]
xor eax, eax
cpuid // serialize again
};
#endif // __GNUC__
return *(__int64*)res; // return result
}
/*/
thanks,
shahzad
RTL explaination
hi,
I'm trying to understand the rtl genrated by gcc for mips processor.I
have read gcc internals by Richard Stallman but there are still some
confusions in the rtl language.
Following is a snippet of code which i'm trying to understand.
(insn 9 6 10 (nil) (set (reg:SI 182)
(mem/f:SI (symbol_ref:SI ("a")) [0 a+0 S4 A32])) -1 (nil)
(nil))
In the above code following part is still unclear to me
[0 a+0 S4 A32])) -1 (nil)
(nil))
Following is the c code for which above rtl is generated :
int a;
main()
{
a=a+1;
}
thanks,
shahzad
Help with following RTL
hi,
Following is a c code .
int a;
main()
{
a=a+1;
}
This RTL generated for this programe for mips processor is
/***/
; Function main
(note 2 0 3 NOTE_INSN_DELETED)
(note 3 2 4 NOTE_INSN_FUNCTION_BEG)
(note 4 3 5 NOTE_INSN_DELETED)
(note 5 4 6 NOTE_INSN_DELETED)
(note 6 5 8 NOTE_INSN_DELETED)
(insn 8 6 9 (nil) (set (reg:SI 182)
(mem/f:SI (symbol_ref:SI ("a")) [0 a+0 S4 A32])) -1 (nil)
(nil))
(insn 9 8 10 (nil) (set (reg:SI 183)
(plus:SI (reg:SI 182)
(const_int 1 [0x1]))) -1 (nil)
(nil))
(insn 10 9 11 (nil) (set (mem/f:SI (symbol_ref:SI ("a")) [0 a+0 S4 A32])
(reg:SI 183)) -1 (nil)
(nil))
(note 11 10 15 NOTE_INSN_FUNCTION_END)
(insn 15 11 16 (nil) (clobber (reg/i:SI 2 v0)) -1 (nil)
(nil))
(insn 16 15 13 (nil) (clobber (reg:SI 181)) -1 (nil)
(nil))
(code_label 13 16 14 1 "" [0 uses])
(insn 14 13 17 (nil) (set (reg/i:SI 2 v0)
(reg:SI 181)) -1 (nil)
(nil))
(insn 17 14 0 (nil) (use (reg/i:SI 2 v0)) -1 (nil)
(nil))
/*/
I'm a newbie in RTL,so please explain what is happening in lines after
(note 11 10 15 NOTE_INSN_FUNCTION_END)
/**/
(insn 15 11 16 (nil) (clobber (reg/i:SI 2 v0)) -1 (nil)
(nil))
(insn 16 15 13 (nil) (clobber (reg:SI 181)) -1 (nil)
(nil))
(code_label 13 16 14 1 "" [0 uses])
(insn 14 13 17 (nil) (set (reg/i:SI 2 v0)
(reg:SI 181)) -1 (nil)
(nil))
(insn 17 14 0 (nil) (use (reg/i:SI 2 v0)) -1 (nil)
(nil))
/***/
thanks,
shahzad
Code Flow for RTL generation
hi, I'm trying to figure out the code flow of gcc.But i'm not been able to locate the location at which an expression is compared with pattern given in .md file. I think .md file is resposible fo generation of emit-insn.c file.But again at which point the functions in emit-insn.c file are called for generation of RTL file. Please tell me where in code the pattern matching is done for RTL generation. thanks, shazad
Re: Code Flow for RTL generation
is there any way in gdb to step backward. On 6/15/06, Andrew Haley <[EMAIL PROTECTED]> wrote: kernel coder writes: > hi, > I'm trying to figure out the code flow of gcc.But i'm not been > able to locate the location at which an expression is compared with > pattern given in .md file. > > I think .md file is resposible fo generation of emit-insn.c > file.But again at which point the functions in emit-insn.c file are > called for generation of RTL file. > > Please tell me where in code the pattern matching is done for RTL > generation. Run cc1 in gdb. Put a breakpoint on make_insn_raw. Go up from that point to find the caller. You'll find that GEN_foo routines are called from a number of places, in particular the expander. Andrew.
gcc-4.1.0 cross-compile for MIPS
hi, I'm trying to cross compile gcc-4.1.0 for mipsel platform.Following is the sequence of commands which i'm using ../gcc-4.1.0/configure --target=mipsel --without-headres --prefix=/home/shahzad/install/ --with-newlib --enable-languages=c make But following error is generated /home/shahzad/mips_gcc/./gcc/xgcc -B/home/shahzad/mips_gcc/./gcc/ -B/home/shahzad/install//mipsel/bin/ -B/home/shahzad/install//mipsel/lib/ -isystem /home/shahzad/install//mipsel/include -isystem /home/shahzad/install//mipsel/sys-include -DHAVE_CONFIG_H -I. -I../../../gcc-4.1.0/libssp -I. -Wall -O2 -g -O2 -MT ssp.lo -MD -MP -MF .deps/ssp.Tpo -c ../../../gcc-4.1.0/libssp/ssp.c -o ssp.o ../../../gcc-4.1.0/libssp/ssp.c:46:20: error: fcntl.h: No such file or directory ../../../gcc-4.1.0/libssp/ssp.c: In function '__guard_setup': ../../../gcc-4.1.0/libssp/ssp.c:70: warning: implicit declaration of function 'open' ../../../gcc-4.1.0/libssp/ssp.c:70: error: 'O_RDONLY' undeclared (first use in this function) ../../../gcc-4.1.0/libssp/ssp.c:70: error: (Each undeclared identifier is reported only once ../../../gcc-4.1.0/libssp/ssp.c:70: error: for each function it appears in.) ../../../gcc-4.1.0/libssp/ssp.c:73: error: 'ssize_t' undeclared (first use in this function) ../../../gcc-4.1.0/libssp/ssp.c:73: error: expected ';' before 'size' . I'm using fedora 5 as development platform and version of gcc installed on system is 4.1.0 thanks, shahzad
gcc port based on MIPS
hi,
I'm trying to port gcc for a processor which is very similar to
MIPS.Today i just tried to compile gcc-4.1.0 for this processor by
changing configuration files.
First i changed the config.sub file in base directory and just added
the name of processor ABC.
Then i changed the configure.ac file in gcc/ subdirectory and added
following lines.
ABC*)
conftest_s='
.section .tdata,"awT",@progbits
x:
.word 2
.text
addiu $4, $28, %tlsgd(x)
addiu $4, $28, %tlsldm(x)
lui $4, %dtprel_hi(x)
addiu $4, $4, %dtprel_lo(x)
lw $4, %gottprel(x)($28)
lui $4, %tprel_hi(x)
addiu $4, $4, %tprel_lo(x)'
tls_first_major=2
tls_first_minor=16
tls_as_opt='-32 --fatal-warnings'
;;
As you can see it was just copy paste of mips*-*-*) option.
Then i did following changes to config.gcc file in gcc/ subdirectory
ABC*)
cpu_type=ABC
;;
- - - - - - - - - - -
- - - -- - - - - - --
ABC*)
tm_file="dbxelf.h elfos.h svr4.h linux.h ${tm_file} ABC/linux.h"
;;
Then i made a directory gcc-4.1.0/gcc/config/ABC/.I copied all files
of gcc-4.1.0/gcc/config/mips to ABC directory and renamed following
files.
mips.h -- ABC.h
mips.md --ABC.md
mips.c --ABC.c
mips-modes.def -ABC-modes.def
mips-protos.h- ABC-protos.h
mips.opt - ABC.opt
But when i issued the make all-gcc command .Following error occured
../../gcc-4.1.0/gcc/config/ABC/ABC.md: unknown mode `V2SF'
Would u please explain why this error is being generated.Also a bit of
explaination of 'V2SF' mode will helpful.
Then i removed the 'V2SF' mode from patterns in ABC.md file.But now
following error was generated.
../../gcc-4.1.0/gcc/config/ABC/ABC.md:228: unknown value
`' for `mode' attribute
../../gcc-4.1.0/gcc/config/ABC/ABC.md:228: unknown value
`' for `mode' attribute
../../gcc-4.1.0/gcc/config/ABC/ABC.md:228: unknown value `'
for `mode' attribute
../../gcc-4.1.0/gcc/config/ABC/ABC.md:228: unknown value `'
for `mode' attribute
Would you please tell me why this error is being generated.
thanks,
shahzad
Re: gcc port based on MIPS
V2SF will be created by the line
VECTOR_MODES (FLOAT, 8);
Yes you are absolutely right.When i changed the name of file
ABC-modes.def to 1ABC-modes.def ,i got the following error
make[1]: *** No rule to make target
`../../gcc-4.1.0/gcc/config/ABC/ABC-modes.def', needed by
`build/genmodes.o'. Stop.
This shows that ABC-modes.def is being used and it has the required macro
VECTOR_MODES (FLOAT, 8);
Then why still the following error is being generated.
> ../../gcc-4.1.0/gcc/config/ABC/ABC.md: unknown mode `V2SF'
As far as my changes to ABC.md file are concerned .They are as fellows
(define_mode_macro ANYF [(SF "TARGET_HARD_FLOAT")
(DF "TARGET_HARD_FLOAT && TARGET_DOUBLE_FLOAT")])
;; (V2SF "TARGET_PAIRED_SINGLE_FLOAT")])
- - - - - -- - - - - - - - - -
-- - - - - - - - - -- - - - -
(define_mode_attr divide_condition
[DF (SF "!TARGET_FIX_SB1 || flag_unsafe_math_optimizations")])
;; (V2SF "TARGET_SB1 && (!TARGET_FIX_SB1 ||
flag_unsafe_math_optimizations)")])
As you can see i just omitted the entries of V2SF.
On 19 Jun 2006 10:40:45 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
"kernel coder" <[EMAIL PROTECTED]> writes:
> But when i issued the make all-gcc command .Following error occured
>
> ../../gcc-4.1.0/gcc/config/ABC/ABC.md: unknown mode `V2SF'
>
> Would u please explain why this error is being generated.Also a bit of
> explaination of 'V2SF' mode will helpful.
V2SF should normally be defined by ABC/ABC-modes.def. It is normally
found by these lines in config.gcc when you run configure:
if test -f ${srcdir}/config/${cpu_type}/${cpu_type}-modes.def
then
extra_modes=${cpu_type}/${cpu_type}-modes.def
fi
V2SF will be created by the line
VECTOR_MODES (FLOAT, 8);
in ABC-modes.def (as copied from mips-modes.def).
> Then i removed the 'V2SF' mode from patterns in ABC.md file.But now
> following error was generated.
>
> ../../gcc-4.1.0/gcc/config/ABC/ABC.md:228: unknown value
> `' for `mode' attribute
> ../../gcc-4.1.0/gcc/config/ABC/ABC.md:228: unknown value
> `' for `mode' attribute
> ../../gcc-4.1.0/gcc/config/ABC/ABC.md:228: unknown value `'
> for `mode' attribute
> ../../gcc-4.1.0/gcc/config/ABC/ABC.md:228: unknown value `'
> for `mode' attribute
>
>
> Would you please tell me why this error is being generated.
Hard to say without knowing what you changed. Did you simply delete
the ANYF macro, or forget to remove the V2SF case from it?
MD file macros are documented here:
http://gcc.gnu.org/onlinedocs/gccint/Macros.html
Ian
Re: gcc port based on MIPS
../../gcc-4.1.0/gcc/config/ABC/ABC.md:228: unknown value `' for `mode' attribute ../../gcc-4.1.0/gcc/config/ABC/ABC.md:228: unknown value `' for `mode' attribute Sorry,these errors were just my mistake.I mistakenly comminted out the following line in ABC.md file (define_mode_attr UNITMODE [(SF "SF") (DF "DF")]) (V2SF "SF")]) That caused the above error to be generated.Now ABC.md file has passed through the compilation process successfully . But the V2SF error still persistes. Would you please tell me that for what the binutils like gas ,ld are called.I know that gcc uses internally the gas and ld to produce final output. But during compilation of gcc ,what role these executables play. On 6/19/06, Andrew Pinski <[EMAIL PROTECTED]> wrote: > > "kernel coder" <[EMAIL PROTECTED]> writes: > > > (define_mode_attr divide_condition > > [DF (SF "!TARGET_FIX_SB1 || flag_unsafe_math_optimizations")]) > > ;; (V2SF "TARGET_SB1 && (!TARGET_FIX_SB1 || > > flag_unsafe_math_optimizations)")]) > > > > > > As you can see i just omitted the entries of V2SF. > > I hope that isn't really what you did, since that would comment out > the "])" close brackes in each case. Except the above line has ]) also :). -- Pinski
Re: gcc port based on MIPS
thanks,There is a macro LEGITIMIZE_RELOAD_ADDRESS.Accroding to gcc internals "It is a C compound statement that attempts to replace x, which is an address that needs reloading, with a valid memory address for an operand of mode mode. win will be a C statement label elsewhere in the code". I'm not been able to comprehend this macro.The explaination is saying that it tries to replace the address with some suitable address.But when will such a situation occur,any example will be helpful.And what is reloading pass.According to gcc internals in this pass pseudo-registers are replaced with hard registers and some are assigned stack slots.Is there anything else which happens in this phase.Is above mentioned macro also has something to do with pass. thanks, shahzad On 20 Jun 2006 00:40:07 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: "kernel coder" <[EMAIL PROTECTED]> writes: > > ../../gcc-4.1.0/gcc/config/ABC/ABC.md:228: unknown value > > `' for `mode' attribute > > ../../gcc-4.1.0/gcc/config/ABC/ABC.md:228: unknown value > > `' for `mode' attribute > > Sorry,these errors were just my mistake.I mistakenly comminted out the > following line in ABC.md file > > (define_mode_attr UNITMODE [(SF "SF") (DF "DF")]) > (V2SF "SF")]) > > That caused the above error to be generated.Now ABC.md file has passed > through the compilation process successfully . > > But the V2SF error still persistes. Well, this works for MIPS (though I suppose you might want to check that), so if you just copy the MIPS files, then this should work for your target. So if it doesn't work, then you either didn't just copy the files, or you didn't update config.gcc correctly. We can't really help you with this. > Would you please tell me that for what the binutils like gas ,ld are > called.I know that gcc uses internally the gas and ld to produce final > output. > But during compilation of gcc ,what role these executables play. They are used to build libgcc, the gcc support library. Ian
PIC code in function prologue
hi,
I'm having some trouble while understanding the following pic
code in function prologue of cris architecture.
if (current_function_uses_pic_offset_table)
{
/* A reference may have been optimized out (like the abort () in
fde_split in unwind-dw2-fde.c, at least 3.2.1) so check that
it's still used. */
push_topmost_sequence ();
got_really_used
= reg_used_between_p (pic_offset_table_rtx, get_insns (), NULL_RTX);
pop_topmost_sequence ();
}
Is this pic offset table ,the same global offset table.Does
current_function_uses_pic_offset_table means that call to current
function is made through GOT.where this variable
(current_function_uses_pic_offset_table) is being set.
What is happening in next 3 lines
push_topmost_sequence ();
got_really_used
= reg_used_between_p (pic_offset_table_rtx, get_insns (), NULL_RTX);
pop_topmost_sequence ();
what does pic_offset_table_rtx contain.
thanks,
shahzad
explaination of some gcc functions
hi, I'm trying to understand the backend code of gcc for MIPS architecture.I'm having some trouble while understanding following functions. 1: push_topmost_sequence(); 2: emit_insn_after(seq,get_insns()); 3: pop_topmost_sequence(); 4: emit_insn_before Would you please explain what's the role of each function.
Re: explaination of some gcc functions
I'm having trouble in understanding the term sequnce in an insn chain.get_insns() actually returns the current instruction.What does the term "sequence" mean,as the name suggests it must be a sequence of instructions ,but in an instruction chain,a single element will be an instruction ,then what is meant by sequence. When push_topmost_sequence is called ,it should push a sequence of instructions ,but an element of insn chain is a single instruction,then which sequence will be pushed. Suppose following is a sequnce of instructions. 1)entry_insns = get_insns (); 2) push_topmost_sequence (); 3) emit_insn_after (entry_insns, get_insns ()); 4) pop_topmost_sequence (); In 1) current insn is saved in entry_insns. what is happening in In 2).Is sequence differnet from insn in an insn chain ,any example will be helpful. In 3) instruction the entry_insns is being put after the instruction obtained through get_insns() .But does get_insns() also increaments the current instruction pointer.If not then shouldn't the same instruction be emitted in 3). Now again which sequnce is being poped out in 4). On 7/1/06, Eric Christopher <[EMAIL PROTECTED]> wrote: kernel coder wrote: > hi, > I'm trying to understand the backend code of gcc for MIPS > architecture.I'm having some trouble while understanding following > functions. I think most of these are obvious, what problems in specific are you having with them? -eric
problem in gcc port based on MIPS
hi, I am trying to write the backend for a processor based on mips.I am facing some problems during compilation of gcc.GAS has been ported for target processor.The store word instruction on ported assembler only supports 16 bit offsets.i.e the only supported format is stw $1,16-bit-offset($2) I modified mips backend to support stw instruction.But during the compilation of crtstuff.c it is generating an instrucion stw $2,p.2249 as this format of instruction is not supported on assembler,an error for illegal operands(p.2249) is being generated. First of all i'm not been able to understand the operand p.2249 as i'm newbie to mips assembly.According to tc-mips.c code in GAS ,it seems to be a 32 address,but still the syntax is not clear to me. Where in mips backend in gcc (mips.md,mips.h,mips.c) such type of offset(p.2249) is being generated because i need to tell the compiler that only allowed offset for stw instruction is 16-bit and generated format should be stw reg,offset(reg) thanks, kernelcoder
reduction of GP registers in MIPS backend
hi,
I'm trying to learn mips backend by making some changes to it.I
just tried to decrease the number of general purpose registers to 25
but following error was generated.
dp-bit.c: In function '__muldf3':
dp-bit.c:953: error: insn does not satisfy its constraints:
(insn 677 231 616 19 dp-bit.c:871 (set (reg/v:DI 24 $24 [orig:55 res2 ] [55])
(reg:DI 2 $2)) 3 {*movdi_32bit} (nil)
(nil))
dp-bit.c:953: internal compiler error: in
reload_cse_simplify_operands, at postreload.c:394
I'm compiling the code by setting -msoft-float option and no floating
point register is being used.
Following are the changes made to mips backend
/*25 general purpose ,2 accumulator, 3 fake ,3 dummy entries *\
#define FIRST_PSEUDO_REGISTER 33
#define FIXED_REGISTERS \
{ \
1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, \
0, 0, 0, 0, 0, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, \
0, \
}
#define CALL_USED_REGISTERS \
{ \
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, \
0, 0, 0, 0, 0, 1, 1, 0, 0, 0, 1, 1, 1, 1, 0, 0, \
0,\
}
#define GP_REG_FIRST 0
#define GP_REG_LAST 24
#define GP_REG_NUM (GP_REG_LAST - GP_REG_FIRST + 1)
#define GP_DBX_FIRST 0
#define MD_REG_FIRST 26
#define MD_REG_LAST 27
#define MD_REG_NUM (MD_REG_LAST - MD_REG_FIRST + 1)
#define MD_DBX_FIRST 25
#define AT_REGNUM (GP_REG_FIRST + 1)
#define HI_REGNUM (MD_REG_FIRST + 0)
#define LO_REGNUM (MD_REG_FIRST + 1)
enum reg_class
{
NO_REGS, /* no registers in set */
PIC_FN_ADDR_REG, /* SVR4 PIC function address register */
V1_REG, /* Register $v1 ($3) used for TLS access. */
LEA_REGS, /* Every GPR except $25 */
GR_REGS, /* integer registers */
HI_REG, /* hi register */
LO_REG, /* lo register */
MD_REGS, /* multiply/divide registers (hi/lo) */
HI_AND_GR_REGS, /* union classes */
LO_AND_GR_REGS,
ALL_REGS, /* all registers */
LIM_REG_CLASSES /* max value + 1 */
};
#define REG_CLASS_CONTENTS
\
{
\
{ 0x, 0x, }, /* no registers */ \
{ 0x0004, 0x, }, /* SVR4 PIC function address register $18*/ \
{ 0x0008, 0x, }, /* only $v1 */ \
{ 0x01bf, 0x, }, /* Every other GPR except $18 */ \
{ 0x01ff, 0x, }, /* integer registers */ \
{ 0x0400, 0x, }, /* hi register */ \
{ 0x0800, 0x, }, /* lo register */ \
{ 0x0c00, 0x, }, /* mul/div registers */ \
{ 0x05ff, 0x, }, /* union classes */ \
{ 0x09ff, 0x, }, \
{ 0x, 0x0001, } /* all registers */ \
}
#define REGISTER_NAMES \
{ "$0", "$1", "$2", "$3", "$4", "$5", "$6", "$7",\
"$8", "$9", "$10", "$11", "$12", "$13", "$14", "$15", \
"$16", "$17", "$18", "$19", "$20", "$21", "$sp", "$fp", \
"$24", "", "hi", "lo", "$arg", "$frame", "", "", \
"", \
}
#define ADDITIONAL_REGISTER_NAMES \
{ \
{ "$22", 22 + GP_REG_FIRST },\
{ "$23", 23 + GP_REG_FIRST },\
{ "at",1 + GP_REG_FIRST },\
{ "v0",2 + GP_REG_FIRST },\
{ "v1",3 + GP_REG_FIRST },\
{ "a0",4 + GP_REG_FIRST },\
{ "a1",5 + GP_REG_FIRST },\
{ "a2",6 + GP_REG_FIRST },\
{ "a3",7 + GP_REG_FIRST },\
{ "t0",8 + GP_REG_FIRST },\
{ "t1",9 + GP_REG_FIRST },\
{ "t2", 10 + GP_REG_FIRST },\
{ "t3", 11 + GP_REG_FIRST },\
{ "t4", 12 + GP_REG_FIRST },\
{ "t5", 13 + GP_REG_FIRST },\
{ "t6", 14 + GP_REG_FIRST },\
{ "t7", 15 + GP_REG_FIRST
Re: reduction of GP registers in MIPS backend
This violates an assumption in mips.c:override_options that GPRs come in pairs.
Thus you end up with (reg/v:DI 24 $24 [orig:55 res2 ] [55]), which does not
satisfy the 'd' constraint.
Would you please give a bit more explaination of "GPRs come in pairs"
and where this assumption is being checked in function
override_options.
thanks,
shaz
On 7/31/06, Joern RENNECKE <[EMAIL PROTECTED]> wrote:
In http://gcc.gnu.org/ml/gcc/2006-07/msg00632.html, you wrote:
dp-bit.c: In function '__muldf3':
dp-bit.c:953: error: insn does not satisfy its constraints:
(insn 677 231 616 19 dp-bit.c:871 (set (reg/v:DI 24 $24 [orig:55 res2 ] [55])
(reg:DI 2 $2)) 3 {*movdi_32bit} (nil)
(nil))
dp-bit.c:953: internal compiler error: in
reload_cse_simplify_operands, at postreload.c:394
please read the documentation in gcc/gcc/doc/ ; this is explained in tm.texi,
under HARD_REGNO_MODE_OK.
> { 0x01ff, 0x, }, /* integer registers */ \
This violates an assumption in mips.c:override_options that GPRs come in pairs.
Thus you end up with (reg/v:DI 24 $24 [orig:55 res2 ] [55]), which does not
satisfy the 'd' constraint.
Register windows implementation in Xtensa backend
hi,
I'm trying to understand the register windows
implementation in xtensa backend.I could not find much theory about
register windows in extensa.I am trying to understand the register
windows implementation by observing the assembly file generated by gcc
for a simple c file.
Following is the c file and generated assembly file
/hello.c**/
int foo(int a)
{
int b;
a=a+1;
b=a;
}
void main(void)
{
int a;
int b;
b=a+1;
foo(b);
}
/*hello.s***/
.file "hello.c"
.text
.align 4
.global foo
.type foo, @function
foo:
.frame a7, 64
entry sp, 64
mov.n a7, sp
s32i.n a2, a7, 16
l32i.n a3, a7, 16
addi.n a3, a3, 1
s32i.n a3, a7, 16
l32i.n a3, a7, 16
s32i.n a3, a7, 0
retw.n
.size foo, .-foo
.align 4
.global main
.type main, @function
main:
.frame a7, 48
entry sp, 48
mov.n a7, sp
l32i.n a8, a7, 4
addi.n a8, a8, 1
s32i.n a8, a7, 0
l32i.n a10, a7, 0
call8 foo
retw.n
.size main, .-main
.ident "GCC: (GNU) 4.1.0"
/***/
Uptill now i've worked with MIPS and intel which use the stack based
argument passing mechnism.So i'm feeling extremly hard to track how
variables are being created and passed to other function in assembly
file.
Would you please give me some explaination about how variables are
being created ,how arguments are being passed and how register window
is being changed for "foo" function.How the argument is being passed
and then retrieved in "foo" function.
In sparc architecture a register window contains three groups of
registers i.e out,in,local.Is there any such kind of division in a
visible window in xtensa.
thanks,
shaz
segmentation fault in building __floatdisf.o
hi,
I'm having some problem during build up of libgcc2 in function
__floatdisf(build up of __floatdisf.o).Actually i'm modifying mips
backend.The error is
../../gcc-4.1.0/gcc/libgcc2.c: In function '__floatdisf':
../../gcc-4.1.0/gcc/libgcc2.c:1354: internal compiler error: Segmentation fault
I tried to debug the reason of crash and following are my findings
before crash following pattern is called
(define_expand "cmp"
[(set (cc0)
(compare:CC (match_operand:GPR 0 "register_operand")
(match_operand:GPR 1 "nonmemory_operand")))]
""
{
fprintf(stderr," cmp \n");
branch_cmp[0] = operands[0];
branch_cmp[1] = operands[1];
debug_rtx(branch_cmp[0]);
debug_rtx(branch_cmp[1]);
DONE;
})
as u can see i've printed the operands which are as follows
operand[0]
--
(subreg:SI (reg:DI 30) 4)
operand[1]
-
(subreg:SI (reg:DI 25 [ u.0 ]) 4)
after this i think it tries to mach some s bCOND pattern but in this
case it fails .
Is this my proposition correct?
In another working case where no error is being generated.Following is
the sequence of called patterns
(define_expand "cmp"
[(set (cc0)
(compare:CC (match_operand:GPR 0 "register_operand")
(match_operand:GPR 1 "nonmemory_operand")))]
""
{
fprintf(stderr," cmp \n");
cmp_operands[0] = operands[0];
cmp_operands[1] = operands[1];
debug_rtx(cmp_operands[0]);
debug_rtx(cmp_operands[1]);
DONE;
})
here the operand are
operands[0]
---
(subreg:SI (reg:DI 30) 0)
operands[1]
---
(subreg:SI (reg:DI 25 [ u.0 ]) 0)
Then the following pattern is matched
(define_expand "bltu"
[(set (pc)
(if_then_else (ltu (cc0) (const_int 0))
(label_ref (match_operand 0 ""))
(pc)))]
""
{
fprintf(stderr,"\n branch_fp 8 bltu\n");
})
So in first failed case it must match the above mentioned pattern but
fails to do so.So the only difference seems to be that bytenum offset
in subreg expression is different.In failed case it is 4 and in
successful case it is 0.
Both directories seems to be copy of each other.Then why operands are
defiierent in cmpsi patterns.There are no floating point registers.The
option passed to gcc is -msoft-float.
I've tried my best to track the problem but could not due my limited
knowledge.Would you please give me some hint to debug the problem .
thanks,
shahzad
Re: segmentation fault in building __floatdisf.o
hi,
Thanks for your explaination.I just figured out the
problem.actually a pattern named "bgtu" was generated by gcc and in
my backend ,i defined all branch patterns except bgtu.So when gcc
tried to match "bgtu" pattern ,it could not find it and generated
above mentioned error.Now i have defined that pattern and it is
compiling without any error.
It was by luck that i figured out that "bgtu" was missing.Would you
please tell me how can i figure out that gcc is trying to match which
pattern.Where in gcc code ,patterns are being matched to those in
backend files.
thanks,
shaz
On 8/30/06, Dave Korn <[EMAIL PROTECTED]> wrote:
On 30 August 2006 15:11, kernel coder wrote:
> hi,
> I'm having some problem during build up of libgcc2 in function
> __floatdisf(build up of __floatdisf.o).Actually i'm modifying mips
> backend.The error is
>
> ../../gcc-4.1.0/gcc/libgcc2.c: In function '__floatdisf':
> ../../gcc-4.1.0/gcc/libgcc2.c:1354: internal compiler error: Segmentation
> fault
This is always the first sign of a bug in your backend, as it's the first
bit of code that gets compiled for the target by the newly-compiled backend.
In this case, it's a really bad bug, because we're bombing out with a SEGV,
rather than getting a nice assert. This could be because of dereferencing a
null pointer.
> before crash following pattern is called
>
> (define_expand "cmp"
> [(set (cc0)
> (compare:CC (match_operand:GPR 0 "register_operand")
> (match_operand:GPR 1 "nonmemory_operand")))]
> ""
> {
> fprintf(stderr," cmp \n");
> branch_cmp[0] = operands[0];
> branch_cmp[1] = operands[1];
> debug_rtx(branch_cmp[0]);
> debug_rtx(branch_cmp[1]);
> DONE;
> })
> (subreg:SI (reg:DI 30) 4)
> (subreg:SI (reg:DI 25 [ u.0 ]) 4)
>
> after this i think it tries to mach some s bCOND pattern but in this
> case it fails .
>
> Is this my proposition correct?
Unlikely. You'd expect to see a proper ICE message with backtrace if recog
failed.
> In another working case where no error is being generated.Following is
> the sequence of called patterns
>
> (define_expand "cmp"
> [(set (cc0)
> (compare:CC (match_operand:GPR 0 "register_operand")
> (match_operand:GPR 1 "nonmemory_operand")))]
> ""
> {
> fprintf(stderr," cmp \n");
> cmp_operands[0] = operands[0];
> cmp_operands[1] = operands[1];
> debug_rtx(cmp_operands[0]);
> debug_rtx(cmp_operands[1]);
> DONE;
> })
> (subreg:SI (reg:DI 30) 0)
> (subreg:SI (reg:DI 25 [ u.0 ]) 0)
>
> Then the following pattern is matched
>
> (define_expand "bltu"
> [(set (pc)
> (if_then_else (ltu (cc0) (const_int 0))
> (label_ref (match_operand 0 ""))
> (pc)))]
> ""
> {
> fprintf(stderr,"\n branch_fp 8 bltu\n");
> })
> I've tried my best to track the problem but could not due my limited
> knowledge.Would you please give me some hint to debug the problem .
I suspect that what's going wrong is that, in the error case, one of the
'branch_cmp' or 'cmp_operands' arrays is getting set, but when the branch
pattern comes to be matched, it is the /other/ array that is used, which is
where the null pointer is coming from.
You've given no information about what you've actually changed, and I'm no
MIPS expert, but in my local copy of the gcc 4 sources there's no such thing
as 'branch_cmp', only 'cmp_operands', whereas in gcc series 3m, it's the other
way round
So I'm guessing that you've added a new variant of the cmp expander,
and you've based it on some old code from a series 3 version of the compiler,
and it's not good in series 4?
cheers,
DaveK
--
Can't think of a witty .sigline today
explaination of trampoline
I was just investigating the trampoline implementation.I have defined
following macros in machine.h file.
#define TRAMPOLINE_SIZE (32 + GET_MODE_SIZE (ptr_mode) * 2)
#define TRAMPOLINE_ALIGNMENT GET_MODE_BITSIZE (ptr_mode)
#define INITIALIZE_TRAMPOLINE(ADDR, FUNC, CHAIN)\
{ \
rtx func_addr, chain_addr;\
\
func_addr = plus_constant (ADDR, 32); \
chain_addr = plus_constant (func_addr, GET_MODE_SIZE (ptr_mode)); \
emit_move_insn (gen_rtx_MEM (ptr_mode, func_addr), FUNC); \
emit_move_insn (gen_rtx_MEM (ptr_mode, chain_addr), CHAIN); \
\
}
The c code for which i'm observing the effect is as follows.
int foo(int (*f)()){
(*f)();
}
main(){
int g(){printf("hello");}
foo(g);
}
But if i comment out the body of macro INITIALIZE_TRAMPOLINE .Nothing
gets changed in the generated assembly file.
According to gcc internals INITIALIZE_TRAMPOLINE is responsible for
initialising the variable parts of a trampoline.
Would you please tell me when does the macros INITIALIZE_TRAMPOLINE
and TRAMPOLINE_TEMPLATE come in effect.Any practical expample will be
helpful.
Trampoline implementation for MIPS
hi,
I'm having some trouble while understanding the generated assembly
code for trampoline by mips back-end.
Following is the code for which i'm trying to undertsand the generated
trampoline code.
int foo(int (*f)()){
(*f)();
}
main(){
int i;
int g(){printf("hello,%d",i);}
foo(g);
}
Parts of generated assembly code which are confusing are
$LTRAMP0:
.word 0x03e00821 # move $1,$31
.word 0x04110001 # bgezal $0,.+8
.word 0x # nop
.word 0x8fe30014 # lw $3,20($31)
.word 0x8fe20018 # lw $2,24($31)
.word 0x0060c821 # move $25,$3 (abicalls)
.word 0x0068 # jr $3
.word 0x0020f821 # move $31,$1
.word 0x #
.word 0x #
.globl _flush_cache
main:
- - - - - - - - - - - -
addiu $sp,$sp,-80
sw $31,72($sp)
sw $fp,68($sp)
sw $16,64($sp)
move$fp,$sp
addiu $2,$fp,20
addiu $16,$2,4
lui $2,%hi($LTRAMP0)
move$3,$16
addiu $2,$2,%lo($LTRAMP0)
li $5,40 # 0x28
move$4,$2
jal memcpy
nop
lui $2,%hi(g.1238)
addiu $2,$2,%lo(g.1238)
sw $2,32($16)
move$3,$16
li $4,40 # 0x28
li $5,3# 0x3
jal _flush_cache
nop
addiu $2,$fp,20
addiu $2,$2,4
move$3,$2
jal foo
nop
A bit of explaination of above code will be helpful
