"LongWord and constant" expressions unnecessarily expand to 64 bits
Original Reporter info from Mantis: Gorelkin
-
Reporter name: Sergei Gorelkin
Original Reporter info from Mantis: Gorelkin
- Reporter name: Sergei Gorelkin
Description:
FPC trunk evaluates "and" operations between 32-bit unsigned operand and a narrower signed constant as 64 bits. The code remains correct, but gets bloated with unnecessary instructions. Therefore it can be detected only by examining the assembler listing. I tested it on i386-win32 and mips-linux.
e.g. in the following example:
var
pdest:pointer;
aligncount:sizeint;
begin
aligncount:=( (sizeof(PtrUInt)-1) and PtrUInt(pdest) ) shr 2;
end.
Here "sizeof(PtrUInt)-1" is 8-bit signed, "and" and shift is done in 64 bits.
FPC 2.6.2 does not have this behavior, my investigation shows that it was due to yet another bug which got fixed when merging i8086 branch: before r24324 the first lines of function defutil.get_common_intdef() were assigning max(ld.low,rd.low) to llow, instead of min(ld.low,rd.low). So get_common_intdef(shortint,longword) was returning longword, while currently it returns int64.
Probably this case should not call get_common_intdef, but promote smaller side to type of opposite larger operand.
Mantis conversion info:
- Mantis ID: 25179
- Platform: all 32-bit
- Version: 2.7.1
- Fixed in revision: 26882 (#888ecdae)
- Target version: 2.7.1