On Tue, Jan 14, 2014 at 02:21:52PM +0000, Kyrill Tkachov wrote:
> If I look at the dump before forwprop, the number of statements is
> exactly the same, so it's not any shorter in that sense.
>
> <Dump from before forwprop>
> IsAwake (struct b2Body * b)
> {
> short unsigned int _3;
> int _4;
> int _5;
> _Bool _6;
>
> <bb 2>:
> _3 = b_2(D)->flags;
> _4 = (int) _3;
> _5 = _4 & 2;
> _6 = _5 != 0;
> return _6;
>
> }
>
> Using shorts is not cheaper on an architecture like arm which is
> word-based. Just the fact that we're introducing shorts already
> implies we're going to have to extend somewhere.
As discussed multiple times in the various type demotion/promotion threads,
for GIMPLE optimizations it is desirable to use as narrow types as possible,
because that e.g. means greater possibilities of finding redundancies,
optimizing away useless computations in the upper bits, canonicalize
computations done in different types etc.
Already the FEs right now narrow types, but only within the same folded
expressions (get_narrower etc.), of course we want to move that away from
FEs if possible and do it during (early?) GIMPLE passes.
Generally, targets should be able to expand good code for the narrower
types, there is no reason why they can't, but perhaps their tasks would be
easier if we did some target hooks/optabs or something driven type
promotion. Anyway, the above is really a simple case, and I'd call it a
backend bug if it isn't able to generate good code out of that.
Jakub
