This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH, take 2] Fix PR target/28946


Rask Ingemann Lambertsen wrote:

PR target/28946
* config/i386/i386.md ("*ashldi3_cconly_rex64", "*ashlsi3_cconly",
"*ashlhi3_cconly", "*ashlqi3_cconly",



Should there be "one_bit" versions of these too? Shifts of one bit set
more flags than shifts of multiple bits.


Yes, but "more flags" is OF only. From the instruction reference pdf:

--cut here--
The OF flag is affected only on 1-bit shifts. For left shifts, the OF flag is set to 0 if the most-significant bit of the result is the same as the CF flag (that is, the top two bits of the original operant were the same); otherwise, it is set to 1. For the SAR instruction, the OF flag is cleared for all 1-bit shifts. For the SHR instruction, the OF flag is set to the most-significant bit of the original operand.
--cut here--


I think that "*ashr*_one_bit_cmp" and "*ashr*_one_bit_cconly" can be constrained by CCNO mode instead of CCGOCmode, because they always clear OF flag. This would remove "test" instruction from "if ((a >> 1) > 0)". Other shifts produce garbage in OF, as far as gcc is concerned.

Regarding "*_one_bit_*" instructions, they disable special "shift by 1" forms of shift operations on i486. It looks that only right shifts are affected on i486. However, H.J. Lu's follow-up commit disables all "shift by >1" compare instructions on TARGET_PARTIAL_FLAG_REG_STALL. Do we need to introduce *_one_bit_* versions also for ashl* patterns, as they should not depend on TARGET_PARTIAL_FLAG_REG_STALL?

BTW: For sure, we can remove check for TARGET_SHIFT1 from _rex 64bit instructions. They are all ~m486.

Uros.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]