At 15:45 2002-10-25 -0700, you wrote:
From: "Ben Combee" <[EMAIL PROTECTED]>
>
> Looking at the C++ standard, the behavior here is determined by section
> 12.8, "Copying class objects".  The implicitly defined copy constructor
has
> several requirements:
>
> 1) perform a memberwise copy of its subobjects
> 2) order of copying is the same as the of initiation of its base classes
> and members in a user-defined constructor

I don't have the standard in front of me, but I would've expected it to say
that an implementation must appear from the outside as if those two
requirements were met, but that it can certainly optimize a simple struct
copy without regard to them. In other words, I do not believe the standard
really requires memberwise copy in implementation.
In general, the standard just requires the appearance that something happened. It says that the implied copy constructor must act like it worked like this, and that is what drove the initial implementation.

> #pragma block_assign on
>
> to your source files or header file.  It is not enabled by default because
> it can cause missed optimization opportunities for some code because the
> compiler is no longer able to split a single struct into multiple scalar
> variables for independent assignment to registers or the stack.

Can't the optimizer tell when it should do a block assignment?
There are two levels here.

The front-end is responsible to generating either a block copy or a memberwise copy. The FE has finished all of its code generation before the optimizer gets a chance to modify things. So, the optimizer now sees you local struct treated both as individual elements and as a whole structure due to the block copy. It doesn't know that that block copy is really a copy constructor, it just sees a much lower level use of the address of the structure, rather than the individual use of each structure element.

On the 68K with the current backend, this optimization isn't very important, so it may be good to default to block_copy on for this compiler. Access from memory don't have a huge penalty on the 68K versus more pipelined chips, and the register pressure is already very high due to the limited number of address and data registers, so there aren't a lot of opportunities to do struct scalarization that there would be on a chip like the PowerPC with its 32 general purpose registers.

--
Ben Combee <[EMAIL PROTECTED]>
CodeWarrior for Palm OS technical lead
Palm OS programming help @ www.palmoswerks.com


--
For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/

Reply via email to