This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [C/C++ PATCH] Don't convert RHS of a shift-expression to int (PR c/63862)
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Richard Biener <rguenther at suse dot de>
- Cc: Jason Merrill <jason at redhat dot com>, Marek Polacek <polacek at redhat dot com>, Joseph Myers <joseph at codesourcery dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 27 Nov 2014 10:45:35 +0100
- Subject: Re: [C/C++ PATCH] Don't convert RHS of a shift-expression to int (PR c/63862)
- Authentication-results: sourceware.org; auth=none
- References: <20141126173944 dot GW29446 at redhat dot com> <20141126175029 dot GM1669 at tucnak dot redhat dot com> <20141126182004 dot GA15555 at redhat dot com> <20141126184955 dot GO1669 at tucnak dot redhat dot com> <54762942 dot 3040803 at redhat dot com> <20141126193352 dot GT1669 at tucnak dot redhat dot com> <331B922F-08DD-4EF5-BE61-394759E2F73D at suse dot de> <20141126212431 dot GA1892 at tucnak dot redhat dot com> <alpine dot LSU dot 2 dot 11 dot 1411271025300 dot 374 at zhemvz dot fhfr dot qr>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
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.
Jakub