[Mono-dev] Mono.Simd AltiVec port

Sergei Dyshel qyron.private at gmail.com
Sun May 2 08:52:09 EDT 2010


Hello Rodrigo and all,

Returning to my old problem which deals with alignment of vector variables.
I noticed that on x86 vector locals are aligned at 8-byte boundary instead
of 16-byte thus causing to use 'movups' instead of much more efficient
'movaps'.
On PowerPC there is no such "bug", so I tried to compare their routines for
locals' allocation.  In 'mini-x86.c', in function 'mono_arch_allocate_vars',
I discovered this strange (to me) piece of code:

         /*
          * EBP is at alignment 8 % MONO_ARCH_FRAME_ALIGNMENT, so if we
          * have locals larger than 8 bytes we need to make sure that
          * they have the appropriate offset.
          */
         if (MONO_ARCH_FRAME_ALIGNMENT > 8 && locals_stack_align > 8)
                 offset += MONO_ARCH_FRAME_ALIGNMENT - sizeof (gpointer) *
2;

AFAIU, 'if's condition satisfied when there are vector locals and in that
case 'offset' is incremented by 16-4*2=8 bytes thus spoiling the alignment.
I tried to remove these lines and didn't notice anything bad, except that
alignment got fixed.
Moreover, there is no such lines in 'mini-amd64.c'.

Can somebody explain to me the meaning of this piece?
-- 
Regards,
Sergei Dyshel


On Thu, Feb 4, 2010 at 03:59, Rodrigo Kumpera <kumpera at gmail.com> wrote:

> Hi Sergei,
>
> On Tue, Feb 2, 2010 at 6:59 AM, Sergei Dyshel <qyron.private at gmail.com>wrote:
>
>> Hello all,
>>
>> I'm currently working on PowerPC port of Mono which utilizes AltiVec SIMD
>> instructions. During the development I've encountered an alignment
>> problem:
>>
>> As far as I understood from running Mono's JIT, stack-allocated
>> Mono.Simd.Vector* types are always aligned by 16 byte bound, but global
>> ones aren't (such as static class members). This is not a problem for SSE
>> which has unaligned load/stores but AltiVec doesn't have them. Instead of
>> implementing misaligned loads/stores for AltiVec I think it's better to
>> force alignment in global variables, as it done in the case of stack.
>>
>
> No, the JIT doesn't align all Vector types to 16 bytes. There are places,
> like spill, code that
> still doesn't do it correctly. Not a lot of work to get there, but still
> not done.
>
>
> If by global variables you mean statics, then making them properly aligned
> is possible with some trickery.
> The only issue alignment issue we can't currently fix are heap objects due
> to how our GC works.
> Our new GC might eventually gain the ability to properly align such
> objects, but this is something
> for the far future.
>
>
>
>> Can somebody help me with that (e.g. point at relevant places in
>> 'mini-ppc.c')?
>>
>
> To fix the alignment of stack variables you need to mess with a bunch of
> places:
>
> -The spill code from mini-codegen.c
> -The var allocation code in mono_allocate_stack_slots (mini.c)
>
> To fix the static storage alignment you need to change the code that
> allocate the statics area
> to use the proper alignment.
>
> This is the same problem as with objects as it uses a gc routine to
> allocate the memory blob.
> Fixing this requires boing deep into the GC, which is not something simple.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20100502/a7592033/attachment-0001.html 


More information about the Mono-devel-list mailing list