[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150906171626.GA4341@openwall.com>
Date: Sun, 6 Sep 2015 20:16:26 +0300
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Large stack alignment
On Sun, Sep 06, 2015 at 12:02:07PM -0500, JimF wrote:
> I fixed things here.
I guess you meant to reply to magnum's message about the performance
impact, rather than to my message about this being either redundant or
insufficient.
> We still must use mem_align(), but now it is a
> define macro, using no writes to memory variables to do this 'magic'.
> Just simply pointer readjustment
>
> Here is the macro:
>
> #define mem_align(a,b)
> (void*)(((char*)(a))+(((b)-1)-(((size_t)((char*)(a))-1)&((b)-1))))
>
> Now to align, just build a buffer that contains align_wanted extra bytes:
>
> unsigned long _buf[whatever_size + (SIMD_ALIGN)/sizeof(unsigned long)];
>
> then use the macro;
> unsigned long *buf = mem_alloc(_buf, SIMD_ALIGN);
>
> buf will be properly aligned somewhere in the range of _buf to
> &((char*)_buf)[0] +SIMD_COEF
That's great, but I think there's still performance impact potential:
all those individual pointers may need their own registers, whereas
without such per-pointer alignment gcc would simply address everything
relative to a single frame pointer register.
Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
