[C/C++ PATCH] Don't convert RHS of a shift-expression to int (PR c/63862)

[Richard Biener]

On November 26, 2014 8:33:52 PM CET, Jakub Jelinek <jakub@redhat.com> wrote:
>On Wed, Nov 26, 2014 at 02:25:54PM -0500, Jason Merrill wrote:
>> How about converting the rhs to unsigned int if it is already
>unsigned?
>
>That is fine.  I'm just worried about the casts to wider types.
>So perhaps just promote and cast to int if the promoted type is
>signed or unsigned if it is unsigned?
>
>E.g. if you have
>long long foo (long long x, long long y, long long z)
>{
>  return x << (y * z);
>}
>and long long multiplication requires say a libcall, while
>int * int can be expanded inline, using long long for shift
>count penalizes the code unnecessarily.  Ditto for
>long long foo (void) __attribute__((const));
>int
>bar (int x)
>{
>  return x << (foo () & ~0xffffffffLL);
>}
>and similar.  I know, we are running here back into the sadly :(
>still missing type demotion and promotion passes, but changing this
>now when those passes are missing can only hurt code.

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...

Richard.

>
>	Jakub