On Sat, Jul 2, 2011 at 12:59 AM, Bernd Schmidt <ber...@codesourcery.com> wrote: > On 07/02/11 00:11, Joseph S. Myers wrote: >> On Fri, 1 Jul 2011, Bernd Schmidt wrote: >> >>>> * The global tree nodes for various modes are suspicious. Why are they >>>> needed at all? >>> >>> Do you mean only the PImode ones or also intQI_type_node etc.? These are >>> used to pick a suitable type in c_common_type_for_size. >> >> All of them. >> >>>> * The c_common_type_for_size code using those nodes is suspicious. Front >>>> ends shouldn't care about modes like that. >>> >>> It doesn't care about the modes, it just picks a suitable one for a >>> given precision. Note that my patch does not introduce this mechanism, >>> it just extends it. >> >> I don't think anything would be worse without it being extended - these >> are generally places that would be improved by removing code for existing >> modes (maybe replaced by calls to build_nonstandard_integer_type if not >> already there) rather than adding it for more. Removing this code would >> require some thought, but I don't think it needs adding to. > > As far as I can tell, type_for_size is used in quite a few places for > optimizations. I've certainly seen intPI_type being used for 40-bit > bitfields, and also for bitsize-types used in variable-length array > calculations. There's a surprising amount of coverage in the testsuite > already using these two features. I suspect we'd lose that capability if > we don't extend this function.
Using type_for_size is bogus, the middle-end should use build_nonstandard_integer_type instead. It should already choose PDImode for 40-bit if available by the code in layout_type(). Richard.
