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: [RFC] use integer types for copies in SRA when mode is not BLK


On Fri, Jun 24, 2005 at 12:12:20AM -0400, Andrew Pinski wrote:
> We copy the struct element by element which is not a good thing really. 
>  There were
> two ways to fix this: force SRA to produce a block copy for case where 
> we don't use
> any fields or any other usage, the other would change SRA to produce an 
> integer
> variable which holds the struct and use VIEW_CONVERT_EXPR.  This patch 
> implements
> the second idea as we also are able to remove copies at the tree level 
> which would
> have been left with the first way.

Not having a virtual-op copy propagation pass is hurting us.

If we had such a thing, do you have a feeling on how this would
affect this case wrt using block copies here?

> For the case about we now produce the code which we produced in 3.4.0 
> and we get
> on the tree level (right before expand):
>   *x = VIEW_CONVERT_EXPR<struct s>(VIEW_CONVERT_EXPR<unsigned int>(*y));
> 
> Comments or is this an abuse of VIEW_CONVERT_EXPR?

It's ok as far as V_C_E is concerned.

But I'm worried that it only fixes a subset of the cases that may
have regressed.  We could perhaps alternately use a set of word sized
BIT_FIELD_EXPRs to fix this for BLKmode aggregates, but now we're
starting to replicate the logic of emit_block_move and that seems
like a really bad move.


r~


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