|
From: Rich C. <rc...@wi...> - 2012-07-16 11:04:15
|
For gcc on x86, -malign-double will do what is needed. According to the man page, this option is automatically enabled for x86-64. Rich On Sat, 30 Jun 2012 16:36:17 +0200 Julian Seward <js...@ac...> wrote: > On Saturday, June 30, 2012, Rich Coe wrote: > > I enabled the printf near the assert to see the values. > > > > > gst 0x3895DF70 352, sh1 0x3895E0D0 352, sh2 0x3895E230 352, spill > > > 0x3895E390 4096 > > > > I'll keep digging. > > I have the impression (although I could be wrong) that this is > pretty simple. Basically the compiler has ignored repeated requests > to 32-align VG_(threadstate) and the 3-per-thread VexGuestArchState > structures, and has instead 16 aligned it. > > One thing you could try is to ask for the type U256 to be 32 aligned, > although that might not be a good idea, and I don't think it will > help. > > I increased the alignment requirement from 16 to 32 on doing AVX > support recently. This was on the basis that the backend would > generate 256-bit expressions into YMM registers, which then would > be saved/reloaded from the guest state area using aligned memory > operations. However, it turned out to be infeasible to generate > 256 bit wide code, because AVX doesn't have enough 256-bit integer > stuff to handle the Memcheck instrumentation of 256-bit AVX floating > point insns. So I fell back to a Plan B of doing 256 bit code > generation using pairs of 128 bit registers. > > Anyway, to cut a long story short, I thought the 32-alignment would be > necessary but actually it isn't. So in the worst case we could back > off to 16-alignment. However, I would prefer not to do that since > there might come a day where 32-alignment is actually necessary. > > J -- Rich Coe rc...@wi... |