[fpc-devel] Unexpected behaviour with intermediate results
sglienke at dsharp.org
Tue Jun 12 15:10:54 CEST 2018
The real bug imo is that is that it even generates shl and shr instructions.
b := (a shl x) shr x should be just compile to b := a for x in 0..24 and a being 8bit (which is what several C++ compilers do afaik)
> On 12 June 2018 at 02:07 "J. Gareth Moreton" <gareth at moreton-family.com> wrote:
> Someone pointed out that if you perform "(x shl 8) shr 8", where x is of
> type Word, the result is always x, even though logic dictates that the
> upper 8 bits should be shifted out and hence the result actually be equal
> to "x and $FF". After analysing the assembly language that's produced, it
> turns out that the optimiser works with the full 32-bits of the register.
> For example:
> is_this_a_bug:=((counter shl 8) shr 8);
> ...becomes the following under -O3 (under -O1, %r13w and %si are replaced
> with references)...
> movzwl %r13w,%eax
> shl $0x8,%eax
> shr $0x8,%eax
> mox %al,%si
> A similar situation happens if the variables are of type Byte as well -
> the intermediate values use the full 32 bits of the register.
> I'm not certain if this is a bug or intended behaviour though. Can
> someone more senior make a decision on this?
> fpc-devel maillist - fpc-devel at lists.freepascal.org
More information about the fpc-devel