Re: bin/46978: internal compiler error building qt4-libs

[David Laight <david%l8s.co.uk@localhost>]

The following reply was made to PR bin/46978; it has been noted by GNATS.

From: David Laight <david%l8s.co.uk@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: bin/46978: internal compiler error building qt4-libs
Date: Mon, 1 Oct 2012 07:52:51 +0100

 On Sun, Sep 30, 2012 at 09:10:08PM +0000, Joerg Sonnenberger wrote:
 > The following reply was made to PR bin/46978; it has been noted by GNATS.
 > 
 > From: Joerg Sonnenberger <joerg%britannica.bec.de@localhost>
 > To: Nick Hudson <skrll%netbsd.org@localhost>
 > Cc: gnats-bugs%netbsd.org@localhost, gnats-admin%netbsd.org@localhost
 > Subject: Re: bin/46978: internal compiler error building qt4-libs
 > Date: Sun, 30 Sep 2012 23:08:45 +0200
 > 
 >  --7AUc2qLy4jB3hD7Z
 >  Content-Type: text/plain; charset=us-ascii
 >  Content-Disposition: inline
 >  
 >  More detailed analysis shows that this happens under the following
 >  conditions:
 >  
 >  (1) MMX is enabled
 >  (2) MMX registers are spilled to the stack
 >  (3) Stack alignment is 32bit
 >  (4) Preferred stack boundary is 32bit too
 >  
 >  What happens is that ix86_local_alignment gets called to create the
 >  stack slot for a MMX register with mode DImode. This is handled as if it
 >  was a "long long" and the 64bit alignment is overriden and downgraded to
 >  32bit.
 >  
 >  The attached patch makes sure that MMX registers use the vector mode,
 >  not DImode for spill slots to distinguish this from "long long".
 
 What effect does that have on the generated coded?
 In particular does it unnecessarily add code to realign the stack?
 The instructions used for MMX registers do not need to 64bit alignment.
 
 IIRC these registers get use for FP and load/store will happen from structure
 members won't be aligned.
 
 There is a slight performance benefit from aligning 64 bit items, but
 this is sensible achieved by hoping to maintain teh stack alignment.
 
        David
 
 -- 
 David Laight: david%l8s.co.uk@localhost