On 07/02/11 15:21:32, Joseph S. Myers wrote: [...] > In general configure options aren't really a good idea in many cases: > > * If something is always best on a particular architecture, maybe you want > a target hook (not macro) rather than a configure option, with the target > hook being set appropriately for each target and no option for the person > configuring GCC to override.
With UPC, the packed pointer-to-shared (PTS) representation takes less space and is generally useful for most applications. However, it is sometimes necessary to allocate more bits for the number of threads, and less for the block offset for example, which makes it possible to continue to use the packed PTS representation in certain applications. This motivates the 'configure' setting. The 'struct' PTS has essentially no limitations but the pointers-to-shared are bigger and accessing the sub-fields of this "fat pointer" is somewhat slower. Also, passing 'struct' based PTS's as arguments (to the runtime for example) can be slower on some architectures. The difficulty with making this representation choice a compile-time selection is that the runtime needs to be aware of the pointer-to-shared layout. Perhaps we could build two separate runtimes (packed PTS and struct PTS) and parameterize the packed PTS based runtime to calculate the shifts and masks it needs rather than compiling them as constants, but that will probably impact performance on various commonly called paths through the runtime. > Even if you need a configure option for the default, the command-line > options may still be useful in some cases for testing and debugging > purposes. Yes, that would be useful.
