Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 6 Sep 2015 20:55:38 +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:30:28PM -0500, JimF wrote:
> On 9/6/2015 12:16 PM, Solar Designer wrote:
> >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.
> 
> Could this be handled with a union, where you define all of the arrays 
> in that union, and then simply move the whole thing forward X number of 
> bytes?

You mean a struct, and yes this is a solution.

> Or would this cause a double access, first to access the pointer 
> of the union, then to offset from that pointer to find the element (then 
> possibly a 3rd to access offset within that buffer) ?

No, it would not cause any extra accesses compared to your current
approach with a pointer to array.  But there will be differences in the
generated code.

> If not, then turning
> 
> type buf1[X];
> type buf2[Y];
> 
> into
> typedef struct {type buf1[x]; type buf2[Y]} buftype;
> char _buf[sizeof(buftype)+align];
> buftype *buf = mem_align(_buf, align);
> 
> How does that look?  Yes, now we have to change all buf1[x] into 
> buf->buf1[x]  but do you see this as just compiler eye candy, or is there 
> still compiler performance issues here ?

Compared to the pointer to array, this should generally be a performance
improvement when you have enough such arrays that register pressure
would be an issue, or it can be a minor performance regression when you
have plenty of registers anyway and the displacements could thus be
avoided.

So this will cost us just one register for all arrays, rather than a
register per array, although ideally we'd have the compiler align the
stack and then we wouldn't spend any extra registers on this.

More importantly, none of this addresses the "redundant or insufficient"
aspect.  We need to figure it out.

Alexander

Powered by blists - more mailing lists

Your e-mail address:

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.