This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: x86 patch: SSE-based FP<=>int conversions, round 1


> On Sat, Dec 02, 2006 at 04:14:27PM +0100, Jan Hubicka wrote:
> > The preferred stakc boundary is needed here because the code do use
> > 128bit temporaries, right?
> > This is not 100% correct since we AFAIK didn't officially decided what
> > out stack alignment strategy on 32bit code is (ie if the preferred stack
> > boundary is just recommendation leading to faster code or actual
> > requirement).
> > 
> > We probably have alternatives here like forcing reload to use misaligned
> > moves (that are unlikely to happen anyway if the SSE spilling was
> > defined expensive as it is in reality) or enforcing the stack alignment.
> > 
> > I would not be quite oposed to decision that 128bit alignment is
> > mandatory on 32bit on some targets, like darwin, but we need some extra
> > switch for that.
> 
> We have pretty much decided mandatory 128bit alignment for 32bit:
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13685
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27537
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28621

Yes, but I guess we still need backup plan for environments we can't
controll (like Win32 I guess).  So far we only had explicit SSE vector
code (or autovectorized) broken.  This way we would break even the
default codegen.
But I would like to see 128bit alignment by default on Linux and such
too.

Honza


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]