Do compilers optimize out net zero bit shifts?

Question

I have some code like the following code block (I am not allowed to post the original code) inside a .cpp file that I think is being compiled by clang++ (Ubuntu clang version 3.5.2-3ubuntu1 (tags/RELEASE_352/final) (based on LLVM 3.5.2)).
It looks like C code, because we are using GoogleTest for testing our C code. Anyways:

size_t const SHIFT = 4; uint8_t var, var2; /* Omitted: Code that sets var to, say 00011000 (base 2) */ var2 = var; var = var << SHIFT >> SHIFT; // [1] result is 00011000 (base 2) (tested with printf) var2 = var2 << SHIFT; var2 = var2 >> SHIFT; // [2] result is 00001000 (base 2) (tested with printf)

Now, why does comment [1] hold true? I was assuming that the corresponding line would result in the top 4 bits being zeroed out. But I found out that this isn't true; the program simply restores the original value.

Is this some language defined behavior, or is clang compiling out a supposedly useless bit shift?

(I checked associativity (using this table on cppreference.com, assuming that associativity/precedence of basic operators won't differ between versions of C++ and probably not between C++ and C either, at least not in 'current versions') and it seems like the RHS expression at [1] should really yield the same result as the two following statements)

Ah lol. Thanks @Mysticial ! Do you care to answer? Otherwise I'll just answer it myself quickly. I guess the takeaway for me is to rather use & instead of left and right shifting... — polynomial_donut
– polynomial_donut, Commented Feb 13, 2018 at 21:17
Also, generally shift left followed by shift right by the same amount of bits, is not the identity operation as you seem to expect. It performs a mask operation. — Jens Gustedt
– Jens Gustedt, Commented Feb 13, 2018 at 21:17
If var isn't initialised then the result is undefined behaviour, which means (among other things) that it is legal if var2 == var, with no shifts produced. — gnasher729
– gnasher729, Commented Feb 13, 2018 at 21:18
@polynomial_donut same flag: clang 5.0.0 ( tested on godbolt.org/g/kXVkQz ) <source>:6:17: warning: implicit conversion loses integer precision: 'int' to 'uint8_t' (aka 'unsigned char') [-Wconversion] — Richard Critten
– Richard Critten, Commented Feb 13, 2018 at 21:32

dbush · Accepted Answer · 2018-02-13 21:30:04Z

What you are seeing is a result of integer promotions. Any value with a type of lower rank than int, when used in an expression, is promoted to int.

This is detail in section 6.3.1.1 of the C standard

2 The following may be used in an expression wherever an int or unsigned int may be used:

An object or expression with an integer type (other than int or unsigned int) whose integer conversion rank is less than or equal to the rank of int and unsigned int.

A bit-field of type _Bool, int, signed int, or unsigned int.

If an int can represent all values of the original type (as restricted by the width, for a bit-field), the value is converted to an int; otherwise, it is converted to an unsigned int. These are called the integer promotions. All other types are unchanged by the integer promotions.

In this case:

var = var << SHIFT >> SHIFT;

var is first promoted to int. This type is at least 16 bits wide, and most likely 32 bits wide. So the value being operated on is 0x00000018. A left shift of 4 results in 0x00000180, and subsequently right shifting results in 0x00000018.

The result is then stored in a uint_8. Since the value fits in a variable of this type, no conversion is required and 0x18 is stored.

Am I wrong by saying var is promoted to size_t aka unsigned int (not int)?
But there can be cases due to promotions that could have unexpected results
@polynomial_donut That is not correct because 1) size_t may be larger than unsigned int, and 2) the standard specifically states that the type of a promoted value is int.
The rule of thumb if you're not interested in language lawyer level of detail is that integer promotion sucks in C and C++. And if you think that's bad, wait till you get to function overloading ambiguities with integer types (numeric types in general).
@Mysticial Luckily, we are working with C, so no C++ voodoo :) (*except for basic unit testing code -_-)

Clifford · Accepted Answer · 2018-02-14 00:03:24Z

The expression:

var = var << SHIFT >> SHIFT;

is not semantically equivelent to

var = var << SHIFT ; var = var >> SHIFT ;

That would require:

var = (uint8_t)(var << SHIFT) >> SHIFT ;

which illustrates the effective difference between the two - the observed behaviour does not require optimisation, rather it is required by language definition with respect to type promotion rules in expressions.

That said, it is also entirely possible that a compiler could optimise out the shifts. Optimisation may not change the result where the behaviour is defined as it is in this case.

Collectives™ on Stack Overflow

Do compilers optimize out net zero bit shifts?

2 Answers 2

7 Comments

Comments

Linked

Hot Network Questions

Collectives™ on Stack Overflow

2 Answers 2

7 Comments

Comments

Linked

Related