RTL

RTL

[SRUTHY C.N.]

Sir,
1:
      At first one of you have replied that int variable's declared will
take 4 byte alignment. Then in the "System V ABI documentation for
intel 386 " , it is given that aggregates like structures etc..take
the alignment of most strictly aligned component..When I declare 2
int and one file pointer they took totally 12 bytes then a structure
has declared in its declaration 3 int & 2 char variables are there
int i,j;        //8 bytes
FILE *fp;       //4 bytes
  struct node
    {int a;
     int b;
     char c;
     int d;
     char e;
    }nd;
  accordig to the ABI documentation (by considering tail & internal
padding) it should take 20 bytes. And it is assigned at offset -48 (int
a) to offset -32 (char e). In between 16 bytes has been skipped.Why is
this happening? if I remove one var (for ex: int b) it will start from
-32 to -20? why this alignment to multiple of 16?

   here target is pentium 3.

2:
  Is RTL representation  dependent on GCC version? In linux 9 gcc version
was 3.2.2 and in linux 7 GCC version was 2.96 and both system is using
same target  pentium 3. and there is slight variation in the RTL file
generated. is it due to change in gcc version or anything else?



                                                  Thanking you,
                                                             SRUTHY C.N.

RTL

[SRUTHY C.N.]

Sir,
1:
      At first one of you have replied that int variable's declared will
take 4 byte alignment. Then in the "System V ABI documentation for
intel 386 " , it is given that aggregates like structures etc..take
the alignment of most strictly aligned component..When I declare 2
int and one file pointer they took totally 12 bytes then a structure
has declared in its declaration 3 int & 2 char variables are there
int i,j;        //8 bytes
FILE *fp;       //4 bytes
  struct node
    {int a;
     int b;
     char c;
     int d;
     char e;
    }nd;
  accordig to the ABI documentation (by considering tail & internal
padding) it should take 20 bytes. And it is assigned at offset -48 (int
a) to offset -32 (char e). In between 16 bytes has been skipped.Why is
this happening? if I remove one var (for ex: int b) it will start from
-32 to -20? why this alignment to multiple of 16?

   here target is pentium 3.

2:
  Is RTL representation  dependent on GCC version? In linux 9 gcc version
was 3.2.2 and in linux 7 GCC version was 2.96 and both system is using
same target  pentium 3. and there is slight variation in the RTL file
generated. is it due to change in gcc version or anything else?



                                                  Thanking you,
                                                             SRUTHY C.N.

RTL

[Sruthy C.N]

Sir,
       In the RTL file (gcc version 3.2.2) there is some instructions(insn
6,8,10,12) which do some manipulations on esp..what is it doing?
why it is not there in RTL file of lower versions like 2.96 ..?
(note 2 0 6 NOTE_INSN_DELETED)

(insn 6 2 8 (parallel[
            (set (reg/f:SI 7 esp)
                (and:SI (reg/f:SI 7 esp)
                    (const_int -16 [0xfffffff0])))
            (clobber (reg:CC 17 flags))
        ] ) -1 (nil)
    (nil))

(insn 8 6 10 (set (reg:SI 59)
        (const_int 0 [0x0])) -1 (nil)
    (expr_list:REG_EQUAL (const_int 0 [0x0])
        (nil)))

(insn 10 8 12 (parallel[
            (set (reg/f:SI 7 esp)
                (minus:SI (reg/f:SI 7 esp)
                    (reg:SI 59)))
            (clobber (reg:CC 17 flags))
        ] ) -1 (nil)
    (nil))

(insn 12 10 3 (set (reg/f:SI 60)
        (reg/f:SI 55 virtual-stack-dynamic)) -1 (nil)
    (nil))

(note 3 12 4 NOTE_INSN_FUNCTION_BEG)

        If we consider the assembly program corresponding to this there is
no such instructions corresponding to this..why? please send me
the reply.



                                    Thanking you,
                                              SRUTHY C.N.

RTL

[Sruthy C.N]

Sir,
       In the RTL file (gcc version 3.2.2) there is some instructions(insn
6,8,10,12) which do some manipulations on esp..what is it doing?
why it is not there in RTL file of lower versions like 2.96 ..?
(note 2 0 6 NOTE_INSN_DELETED)

(insn 6 2 8 (parallel[
            (set (reg/f:SI 7 esp)
                (and:SI (reg/f:SI 7 esp)
                    (const_int -16 [0xfffffff0])))
            (clobber (reg:CC 17 flags))
        ] ) -1 (nil)
    (nil))

(insn 8 6 10 (set (reg:SI 59)
        (const_int 0 [0x0])) -1 (nil)
    (expr_list:REG_EQUAL (const_int 0 [0x0])
        (nil)))

(insn 10 8 12 (parallel[
            (set (reg/f:SI 7 esp)
                (minus:SI (reg/f:SI 7 esp)
                    (reg:SI 59)))
            (clobber (reg:CC 17 flags))
        ] ) -1 (nil)
    (nil))

(insn 12 10 3 (set (reg/f:SI 60)
        (reg/f:SI 55 virtual-stack-dynamic)) -1 (nil)
    (nil))

(note 3 12 4 NOTE_INSN_FUNCTION_BEG)

        If we consider the assembly program corresponding to this there is
no such instructions corresponding to this..why? please send me
the reply.



                                    Thanking you,
                                              SRUTHY C.N.

Re: RTL

[Jim Wilson]

Sruthy C.N wrote:
>        In the RTL file (gcc version 3.2.2) there is some instructions(insn
> 6,8,10,12) which do some manipulations on esp..what is it doing?

As I mentioned in a previous message, it is aligning the stack in main 
to a 16 byte boundary.  I believe this is for the MMX/SSE/SSE2 
instructions, which are faster if the stack is 16 byte aligned.  Some 
systems don't align the stack to 16 bytes at program startup, so we do 
it in main.  This extra instruction only occurs in the main function.

>         If we consider the assembly program corresponding to this there is
> no such instructions corresponding to this..why? 

Please give a testcase.  I suspect you got your examples mixed up.  Or 
maybe it got optimized away, though that seems unlikely.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: RTL

[Sruthy C.N]

Sir,
    you told that stack is 16 byte aligned for the MMX/SSE/SSE2
instructions..I can see that the structure and array declarations are
also 16 byte aligned..is this also for the same purpose?..

    In the RTl file all the strings will be replaced by some *.LC0 *.LC1
etc..where exactly is this strings stored? how  you are accessing it?
       Reply me please..
                                          thanking you ,
                                            Sruthy C.N.

SRUTHY C.N.

> Sruthy C.N wrote:
>>        In the RTL file (gcc version 3.2.2) there is some
>> instructions(insn
>> 6,8,10,12) which do some manipulations on esp..what is it doing?
>
> As I mentioned in a previous message, it is aligning the stack in main
> to a 16 byte boundary.  I believe this is for the MMX/SSE/SSE2
> instructions, which are faster if the stack is 16 byte aligned.  Some
> systems don't align the stack to 16 bytes at program startup, so we do
> it in main.  This extra instruction only occurs in the main function.
>
>>         If we consider the assembly program corresponding to this
>> there is
>> no such instructions corresponding to this..why?
>
> Please give a testcase.  I suspect you got your examples mixed up.  Or
> maybe it got optimized away, though that seems unlikely.
> --
> Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: RTL

[Jim Wilson]

On Tue, 2003-09-30 at 05:10, Sruthy C.N wrote:
>     you told that stack is 16 byte aligned for the MMX/SSE/SSE2
> instructions..I can see that the structure and array declarations are
> also 16 byte aligned..is this also for the same purpose?..

This isn't specific enough.  Are you looking at compiler output or
compiler source code?  If you are looking at compiler output, then you
might be seeing various effects that may or may not be guaranteed.  You
might be getting 16-byte alignment by accident.  Using something like
__alignof() will give much more accurate answers than looking at
assembly code.  Also, alignment depends on the structure/array type
declarations, but since you haven't given me an example, I can't be sure
what you are seeing.  Providing a testcase is often the best way to ask
a question.  I can't emphasize that enough.

The following testcase for instance clearly shows that a structure with
one char has only 1 byte alignment.

struct foo { char c; };

int
main (void)
{
  struct foo bar;
  struct foo baz;

  printf ("%d\n", __alignof (bar));
  printf ("%p\n", &bar);
  printf ("%d\n", __alignof (baz));
  printf ("%p\n", &baz);
  return 0;
}


>     In the RTl file all the strings will be replaced by some *.LC0 *.LC1
> etc..where exactly is this strings stored? how  you are accessing it?

These are constant pool references.  Accesses to the constant pool are
target dependent.  The compiler collects string constants and other
constant data items that are too large to be instruction immediates,
eliminates duplicates, and then emits them into a read only data
section.  Many parts of this are target dependent.  Constant pool
entries are preceded by a label which is used for loading the constant
into registers, or copying it to some other part of memory.

If you look at the assembly output instead of the RTL, you can see the
constant pool items.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: RTL

[Sruthy C.N]

Sir,
    you told that stack is 16 byte aligned for the MMX/SSE/SSE2
instructions..I can see that the structure and array declarations are
also 16 byte aligned..is this also for the same purpose?..

    In the RTl file all the strings will be replaced by some *.LC0 *.LC1
etc..where exactly is this strings stored? how  you are accessing it?
       Reply me please..
                                          Thanking you ,
                                            Sruthy C.N.

SRUTHY C.N.

> Sruthy C.N wrote:
>>        In the RTL file (gcc version 3.2.2) there is some
>> instructions(insn
>> 6,8,10,12) which do some manipulations on esp..what is it doing?
>
> As I mentioned in a previous message, it is aligning the stack in main
> to a 16 byte boundary.  I believe this is for the MMX/SSE/SSE2
> instructions, which are faster if the stack is 16 byte aligned.  Some
> systems don't align the stack to 16 bytes at program startup, so we do
> it in main.  This extra instruction only occurs in the main function.
>
>>         If we consider the assembly program corresponding to this
>> there is
>> no such instructions corresponding to this..why?
>
> Please give a testcase.  I suspect you got your examples mixed up.  Or
> maybe it got optimized away, though that seems unlikely.
> --
> Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

RTL

[SRUTHY C.N.]

Sir,
1:
      At first one of you have replied that int variable's declared will
take 4 byte alignment. Then in the "System V ABI documentation for
intel 386 " , it is given that aggregates like structures etc..take
the alignment of most strictly aligned component..When I declare 2
int and one file pointer they took totally 12 bytes then a structure
has declared in its declaration 3 int & 2 char variables are there
int i,j;        //8 bytes
FILE *fp;       //4 bytes
  struct node
    {int a;
     int b;
     char c;
     int d;
     char e;
    }nd;
  accordig to the ABI documentation (by considering tail & internal
padding) it should take 20 bytes. And it is assigned at offset -48 (int
a) to offset -32 (char e). In between 16 bytes has been skipped.Why is
this happening? if I remove one var (for ex: int b) it will start from
-32 to -20? why this alignment to multiple of 16?

   here target is pentium 3.

2:
  Is RTL representation  dependent on GCC version? In linux 9 gcc version
was 3.2.2 and in linux 7 GCC version was 2.96 and both system is using
same target  pentium 3. and there is slight variation in the RTL file
generated. is it due to change in gcc version or anything else?



                                                  Thanking you,
                                                             SRUTHY C.N.

RTL

[SRUTHY C.N.]

Sir,
1:
      At first one of you have replied that int variable's declared will
take 4 byte alignment. Then in the "System V ABI documentation for
intel 386 " , it is given that aggregates like structures etc..take
the alignment of most strictly aligned component..When I declare 2
int and one file pointer they took totally 12 bytes then a structure
has declared in its declaration 3 int & 2 char variables are there
int i,j;        //8 bytes
FILE *fp;       //4 bytes
  struct node
    {int a;
     int b;
     char c;
     int d;
     char e;
    }nd;
  accordig to the ABI documentation (by considering tail & internal
padding) it should take 20 bytes. And it is assigned at offset -48 (int
a) to offset -32 (char e). In between 16 bytes has been skipped.Why is
this happening? if I remove one var (for ex: int b) it will start from
-32 to -20? why this alignment to multiple of 16?

   here target is pentium 3.

2:
  Is RTL representation  dependent on GCC version? In linux 9 gcc version
was 3.2.2 and in linux 7 GCC version was 2.96 and both system is using
same target  pentium 3. and there is slight variation in the RTL file
generated. is it due to change in gcc version or anything else?



                                                  Thanking you,
                                                             SRUTHY C.N.

Re: RTL

[Jim Wilson]

SRUTHY C.N. wrote:
>  why this alignment to multiple of 16?

This is an incomplete bug report.  It is important to give testcases, 
compiler options, compiler versions, etc.

It is probably an accident of implementation.  You can use __alignof() 
to get the structure alignment, and see that it is only 4.  However, we 
need to align the stack in the function main to 16-bytes because 16-byte 
alignment gives better code, and not all systems have startup code that 
give a 16-byte aligned stack.  So if your testcase defines the structure 
in main, it might appear to have 16-byte alignment but it really 
doesn't.  Define the structure in a function with any other name, and 
you will see differently.  This probably would have been obvious if you 
had bothered to include a testcase.

>   Is RTL representation  dependent on GCC version? 

The format changes infrequently.  The contents change frequently, since 
they depend on gcc features and optimizations which change all of the time.

gcc-2.96 to gcc-3.2 is really a very long time in terms of gcc 
development, because of how rapidly gcc changes.  You can't expect 
things to be the same between those two versions.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

rtl

[N V Krishna]

Hi,
	In the file rtl.h I find in the definition of rtx, the field fld
is an array of size 1, declared as :

rtunion fld[1];

However, I see that there are uses as :

#define SET_DEST(RTX) ((RTX)->fld[0].rtx)
#define SET_SRC(RTX) ((RTX)->fld[1].rtx)

Am I missing something obvious?

Warm regards
Krishna
-- 
Homepage:http://www.cs.purdue.edu/homes/nvk

Re: rtl

[Shekhar Divekar]

The size is taken care of during allocation of rtx.

Have a look at the rtx_alloc() for allocation of rtx
after some wrapping functions and macros the core 
code looks like (in ggc.h)

#define ggc_alloc_rtx(NSLOTS)						  \
  ((struct rtx_def *) ggc_alloc (sizeof (struct rtx_def)		  \
				 + ((NSLOTS) - 1) * sizeof (rtunion)))

The additional size allocated takes care of fld[]

The size NSLOTS is nothing but number of fields
which is calculated in rtl.c as follows

#define DEF_RTL_EXPR(ENUM, NAME, FORMAT, CLASS)   sizeof FORMAT - 1 ,

const unsigned char rtx_length[NUM_RTX_CODE] = {
#include "rtl.def"
};


Correct me if I am wrong.

Regards
Shekhar







N V Krishna wrote:

>Hi,
>    In the file rtl.h I find in the definition of rtx, the field fld
>is an array of size 1, declared as :
>
>rtunion fld[1];
>
>However, I see that there are uses as :
>
>#define SET_DEST(RTX) ((RTX)->fld[0].rtx)
>#define SET_SRC(RTX) ((RTX)->fld[1].rtx)
>
>Am I missing something obvious?
>
>Warm regards
>Krishna
>  
>

-- 
Your favorite stores, helpful shopping tools and great gift ideas. 
Experience the convenience of buying online with Shop@Netscape! 
http://shopnow.netscape.com/

Re: rtl

[Mike Stump]

On Thursday, October 3, 2002, at 11:51 PM, N V Krishna wrote:
> the definition of rtx, the field fld is an array of size 1, declared 
> as :
>
> rtunion fld[1];
>
> However, I see that there are uses as :
>
> #define SET_DEST(RTX) ((RTX)->fld[0].rtx)
> #define SET_SRC(RTX) ((RTX)->fld[1].rtx)
>
> Am I missing something obvious?

I'd just recommend ignoring it, unless you want to learn more than you 
wanted to know.  If you want to learn, set a breakpoint at something 
that allocates an rtx and say step.  You will then `see' how this 
works.  This is only one weird thing out of the thousands of weird 
things gcc does.