How to set the alignment

How to set the alignment

[Mohamed Shafi]

Hello all,

I am doing a private port in GCC 4.4.0. For my target the following
are the alignment requirements:

int - 4 bytes
short - 2 bytes
char - 1 byte
pointer - 4 bytes
stack pointer - 4 bytes

i am not able to implement the alignment for short.

The following is are the macros that i used for this

#define PARM_BOUNDARY 8
#define STACK_BOUNDARY 64

I have also defined STACK_SLOT_ALIGNMENT. but this is not affecting the output.

What should i be doing to get the required alignment?

Regards,
Shafi

Re: How to set the alignment

[Jim Wilson]

On 08/03/2009 02:14 AM, Mohamed Shafi wrote:
> short - 2 bytes
> i am not able to implement the alignment for short.
> The following is are the macros that i used for this
> #define PARM_BOUNDARY 8
> #define STACK_BOUNDARY 64

You haven't explained what the actual problem is.  Is there a problem 
with global variables?  Is the variable initialized or uninitialized? 
If it is uninitialized, is it common?  If this a local variable?  Is 
this a function argument or parameter?  Is this a named or unnamed 
(stdarg) argument or parameter?  Etc.  It always helps to include a 
testcase.

You should also mention what gcc is currently emitting, why it is wrong, 
and what the output should be instead.

All this talk about stack and parm boundary suggests that it might be an 
issue with function arguments, in which case you will probably have to 
describe the calling conventions a bit so we can understand what you want.

Jim

Re: How to set the alignment

[Mohamed Shafi]

2009/8/3 Jim Wilson <wilson@codesourcery.com>:
> On 08/03/2009 02:14 AM, Mohamed Shafi wrote:
>>
>> short - 2 bytes
>> i am not able to implement the alignment for short.
>> The following is are the macros that i used for this
>> #define PARM_BOUNDARY 8
>> #define STACK_BOUNDARY 64
>
> You haven't explained what the actual problem is.  Is there a problem with
> global variables?  Is the variable initialized or uninitialized? If it is
> uninitialized, is it common?  If this a local variable?  Is this a function
> argument or parameter?  Is this a named or unnamed (stdarg) argument or
> parameter?  Etc.  It always helps to include a testcase.
>
> You should also mention what gcc is currently emitting, why it is wrong, and
> what the output should be instead.
>
> All this talk about stack and parm boundary suggests that it might be an
> issue with function arguments, in which case you will probably have to
> describe the calling conventions a bit so we can understand what you want.
>
  This is the test case that i tried

short funs (int a, int b, char w,short e,short r)
{
  return e+r;
}

The target is 32bit . The first two parameters are passed in registers
and the rest in stack. For the parameters that are passed in stack the
alignment is that of the data type. The stack pointer is 8 byte
aligned. char is 1 byte, int is 4 byte and short is 2 byte. The code
that is getting generated is give below (-O0 -fomit-frame-pointer)

funs:
        add      16,sp
        mov  d0,(sp-16)
        mov  d1,(sp-12)
        movh  (sp-19),d0
        movh  d0,(sp-8)
        movh  (sp-21),d0
        movh  d0,(sp-6)
        movh  (sp-8),d1
        movh  (sp-6),d0
        add     d1,d0,d0
        sub    16,sp
        ret


From the above code you can see that some of the half word access is
not aligned on a 2byte boundary.

So where am i going wrong.
Hope this info is enough

Regards,
Shafi

Re: How to set the alignment

[Jean Christophe Beyler]

I had a similar issue on my port. I fixed it by adding a check_move
before the generation of the move to look at the potential offset
used.

That allowed the compiler to not generate those wrong offsets
depending on the mode on my port. It looks something like this :

/* Check the operands of the move to make sure we can perform the move */
bool check_move (rtx op0, rtx op1)
{
    /* First check offsets */
    if (MEM_P (op0))
    {
        int offset;
        int res = rtx_get_offset (XEXP (op0, 0), &offset);

        if (res < 0)
            return false;

        if (! cyclops_check_offset (offset, GET_MODE (op0)))
        {
            return false;
        }
    }

    /* Check second operand */
    if (MEM_P (op1))
    {
        int offset;
        int res = rtx_get_offset (XEXP (op1, 0), &offset);

        if (res < 0)
            return false;

        if (! cyclops_check_offset (offset, GET_MODE (op1)))
        {
            return false;
        }
    }

    return true;
}

Jc

On Tue, Aug 4, 2009 at 1:39 AM, Mohamed Shafi<shafitvm@gmail.com> wrote:
> 2009/8/3 Jim Wilson <wilson@codesourcery.com>:
>> On 08/03/2009 02:14 AM, Mohamed Shafi wrote:
>>>
>>> short - 2 bytes
>>> i am not able to implement the alignment for short.
>>> The following is are the macros that i used for this
>>> #define PARM_BOUNDARY 8
>>> #define STACK_BOUNDARY 64
>>
>> You haven't explained what the actual problem is.  Is there a problem with
>> global variables?  Is the variable initialized or uninitialized? If it is
>> uninitialized, is it common?  If this a local variable?  Is this a function
>> argument or parameter?  Is this a named or unnamed (stdarg) argument or
>> parameter?  Etc.  It always helps to include a testcase.
>>
>> You should also mention what gcc is currently emitting, why it is wrong, and
>> what the output should be instead.
>>
>> All this talk about stack and parm boundary suggests that it might be an
>> issue with function arguments, in which case you will probably have to
>> describe the calling conventions a bit so we can understand what you want.
>>
>  This is the test case that i tried
>
> short funs (int a, int b, char w,short e,short r)
> {
>  return e+r;
> }
>
> The target is 32bit . The first two parameters are passed in registers
> and the rest in stack. For the parameters that are passed in stack the
> alignment is that of the data type. The stack pointer is 8 byte
> aligned. char is 1 byte, int is 4 byte and short is 2 byte. The code
> that is getting generated is give below (-O0 -fomit-frame-pointer)
>
> funs:
>        add      16,sp
>        mov  d0,(sp-16)
>        mov  d1,(sp-12)
>        movh  (sp-19),d0
>        movh  d0,(sp-8)
>        movh  (sp-21),d0
>        movh  d0,(sp-6)
>        movh  (sp-8),d1
>        movh  (sp-6),d0
>        add     d1,d0,d0
>        sub    16,sp
>        ret
>
>
> From the above code you can see that some of the half word access is
> not aligned on a 2byte boundary.
>
> So where am i going wrong.
> Hope this info is enough
>
> Regards,
> Shafi
>

Re: How to set the alignment

[Jim Wilson]

On Tue, 2009-08-04 at 11:09 +0530, Mohamed Shafi wrote:
> >> i am not able to implement the alignment for short.
> >> The following is are the macros that i used for this
> >> #define PARM_BOUNDARY 8
> >> #define STACK_BOUNDARY 64
> The target is 32bit . The first two parameters are passed in registers
> and the rest in stack. For the parameters that are passed in stack the
> alignment is that of the data type. The stack pointer is 8 byte
> aligned. char is 1 byte, int is 4 byte and short is 2 byte. The code
> that is getting generated is give below (-O0 -fomit-frame-pointer)

Er, wait.  You set PARM_BOUNDARY to 8.  This means all arguments will be
padded to at most an 8-bit boundary, which means that yes, a short after
a char will have only 1 byte alignment.  If you want all arguments to
have 2-byte alignment, then you need to set PARM_BOUNDARY to 16.  But
you probably want a value of 32 here so that 4-byte ints get 4-byte
alignment.  This will allocate a minimum 4-byte stack slot for every
argument.  I don't know the calling convention, so I don't know exactly
how you want arguments arranged on the stack.

If you are pushing arguments, then you can lie in the PUSH_ROUNDING
macro.  You could say for instance that one byte pushes always push 2
bytes.  This ensures that the stack always has 2-byte alignment while
pushing arguments.  If your push instruction doesn't actually do this,
then you need to modify the pushqi pattern to emit two pushes or use a
HImode push to get the right behaviour.

Try looking at the code in store_one_arg in calls.c, and emit_push_insn
in expr.c.

Jim

Re: How to set the alignment

[Mohamed Shafi]

2009/8/5 Jim Wilson <wilson@codesourcery.com>:
> On Tue, 2009-08-04 at 11:09 +0530, Mohamed Shafi wrote:
>> >> i am not able to implement the alignment for short.
>> >> The following is are the macros that i used for this
>> >> #define PARM_BOUNDARY 8
>> >> #define STACK_BOUNDARY 64
>> The target is 32bit . The first two parameters are passed in registers
>> and the rest in stack. For the parameters that are passed in stack the
>> alignment is that of the data type. The stack pointer is 8 byte
>> aligned. char is 1 byte, int is 4 byte and short is 2 byte. The code
>> that is getting generated is give below (-O0 -fomit-frame-pointer)
>
> Er, wait.  You set PARM_BOUNDARY to 8.  This means all arguments will be
> padded to at most an 8-bit boundary, which means that yes, a short after
> a char will have only 1 byte alignment.  If you want all arguments to
> have 2-byte alignment, then you need to set PARM_BOUNDARY to 16.  But
> you probably want a value of 32 here so that 4-byte ints get 4-byte
> alignment.  This will allocate a minimum 4-byte stack slot for every
> argument.  I don't know the calling convention, so I don't know exactly
> how you want arguments arranged on the stack.
>
> If you are pushing arguments, then you can lie in the PUSH_ROUNDING
> macro.  You could say for instance that one byte pushes always push 2
> bytes.  This ensures that the stack always has 2-byte alignment while
> pushing arguments.  If your push instruction doesn't actually do this,
> then you need to modify the pushqi pattern to emit two pushes or use a
> HImode push to get the right behaviour.
>
> Try looking at the code in store_one_arg in calls.c, and emit_push_insn
> in expr.c.
>
    What i did was to define FUNCTION_ARG_BOUNDARY macro to return the
alignment as per the requirement. i.e 8bits for char, 16bits for
short, 32bits for int and kept PARM_BOUNDARY to 8. Now the complier is
emitting the alignment prperly.

Is this OK?

Regards,
Shafi