On Fri, Apr 18, 2014 at 11:03 AM, chen <chenm...@163.com> wrote: > At 2014-04-19 01:47:16,"Jason Garrett-Glaser" <ja...@x264.com> wrote: > >>> In this case, they pass a align stack to our code, but cglobal push 3 >>> registers, so broken stack align. >> >>I don't understand what you mean. x264asm knows what the stack >>alignment is, so when it allocates scratch space, it references >>aligned locations on the stack. It doesn't matter how many registers >>it pushes; if it pushes 12 bytes of registers, it references locations >>that are 12 bytes off from where it would if there were no registers >>pushed. >> >>"esp" itself may not be aligned, but that's fine, because no data is >>ever accessed directly from esp -- it's accessed from aligned >>locations on the stack. That's how stack alignment works. esp only >>needs to be aligned if the function calls another function, but >>x264asm is for leaf functions, so that doesn't apply. >> > In the x264asm header, I found the doc "%4 = (optional) stack size to be > allocated. If not aligned, the stack will be manually aligned (to 16 or 32 > bytes)" > I guess it means we can alloc some space on stack, and x264asm will let it > align to 16 ort 32 bytes bound, am I right? > > In this case, x264asm don't do it because HAVE_ALIGNED_STACK=1 > the input stack is aligned, but we need push 3 regs into stack, so we got a > stack mistake.
Again, that's not how it works. HAVE_ALIGNED_STACK means x264asm can assume the input stack is aligned. It does not mean x264asm magically stops handling stack alignment. HAVE_ALIGNED_STACK exists to compensate for compilers such as Intel's that don't perform stack alignment. It has _absolutely nothing_ to do with x264asm's own pushing registers onto the stack. Jason _______________________________________________ x265-devel mailing list x265-devel@videolan.org https://mailman.videolan.org/listinfo/x265-devel