This is the mail archive of the gcc@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: remarks about g++ 4.3 and some comparison to msvc & icc on ia32


> Jan Hubicka wrote:
> 
> > I though the comment was more reffering to fact that we will happily
> > generate
> > movl $0x0,  place1
> > movl $0x0,  place2
> > ...
> > movl $0x0,  placeMillion
> > 
> > rather than shorter
> > xor %eax, %eax
> > movl %eax, ...
> 
> Yes, that would be an improvement, but, as you say, at some point we
> want to call memset.
> 
> > With the repeated mov issue unforutnately I don't know what would be the
> > best place: we obviously don't want to constrain register allocation too
> > much and after regalloc I guess only machine dependent pass
> 
> I would hope that we could notice this much earlier than that.  Wouldn't
> this be evident even at the tree level or at least after
> stack-allocation in the RTL layer?  I wouldn't expect the zeroing to be
> coming from machine-dependent code.

What I meant is the generic problem that constants on i386 (especially
for moves) increase instruction encoding and thus when mutiple copies of
the same constant appears in the instruction stream and register is
available one can add extra move and use that register instead.

Of course we can also have pass detecting large sets of unwound mov
instructions and pack them into memset. We can do it either at early RTL
level or with some lowering of initializers at tree level too (I guess
many of those sequences actally come from expanding initializers that
are sort of black boxes for most tree optimizers).

Sort of similar transformation is done by Tomas who can use vectorizer
infrastructure to detect loops doing memset/memcpy.  Those are pretty
common especially for floats/doubles and after unrolling also loeads to
such a sequences.  I hope he will polish and send the patch soonish.

Honza
> 
> One possibility is that we're doing something dumb with arrays.  Another
> possibility is that we're SRA-ing a lot of small structures, which add
> up to a ton of stack space.
> 
> I realize that we need a full bug report to be sure, though.
> 
> -- 
> Mark Mitchell
> CodeSourcery
> mark@codesourcery.com
> (650) 331-3385 x713


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