On Thu, 27 Nov 2014, Jakub Jelinek wrote: > On Thu, Nov 27, 2014 at 10:30:16AM +0100, Richard Biener wrote: > > 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). > > My point is that because we don't have infrastructure for that in GCC 5, > I think it would be best to keep the status quo in GIMPLE for this, and only > when we have infrastructure to do something better, change it. > As Marek wants to have the original (promoted) type in the FEs (which is of > course desirable, not only for ubsan, but also for diagnostics), > transforming that into the old way in c_gimplify_expr would keep the > middle-end seeing what it was used to.
But then rather than using integer_type_node I'd convert to unsigned_type_node (if that doesn't work you know we have some nasty dependence on negative shift counts "working") Richard.
