On Wed, 26 Nov 2014, Jakub Jelinek wrote: > On Wed, Nov 26, 2014 at 10:20:39PM +0100, Richard Biener wrote: > > Well, if you want to aggressively prune unused bits then you could > > "back-propagate" the shift count value-range. > > > > And note that all the frontend shorten-optimizations should move to the > > middle-end. > > > > That said, instead of casting to int we could cast to unsigned char... > > As long as we don't have > 256 bitsize integers, yes, for the purposes of > GIMPLE. Though, as with type demotion, then it might be worthwhile to try > to promote it to wider type if the shift instructions operate on wider shift > count modes than QImode.
True. I suppose the promotion pass could promote/demote the shift count to a mode appropriate for the target. But that's again orthogonal to optimizing the computation of the shift count based on its value-range which does not invoke undefined behavior (thus, shortening of those computations). We don't have a pass yet that allows this kind of "back"-propagation though of course a simple shortening pass wouldn't be hard to implement (or similar to what the FEs do now we can add some patterns to match.pd catching those opportunities). Richard.
