Hi Richard,
>> This patch tweaks the way that min and max are expanded, so that the >> semantics of these operations are visible to the early RTL >> optimization passes, until split into explicit comparison and >> conditional move instructions. > > Btw, I'm sure some variants of those are in bugzilla as well. Now that you mention it, I'm not sure whether PR rtl-optimization 94543 is a bug at all, but with you and Richard Henderson weighing in, I suspect that I must be missing something subtle. The initial text of the bug report complains about an AND of 0xff not being optimized away, as a zero extension is still present. I believe that the AND with 0xff has been completely optimized away, and the remaining movzwl (not movzbl) is the zero extension of the short result to the integer ABI return type. If the result is written as a short to memory, there is no extension (or AND). But perhaps the problem isn't with min/and at all, but about whether function arguments and return values are guaranteed to be extended on input/return, so perhaps this is related to SUBREG_PROMOTED_P and friends? Thoughts? Cheers, Roger > 2020-07-30 Roger Sayle <ro...@nextmovesoftware.com> > > * config/i386/i386.md (MAXMIN_IMODE): No longer needed. > (<maxmin><mode>3): Support SWI248 and general_operand for > second operand, when TARGET_CMOVE. > (<maxmin><mode>3_1 splitter): Optimize comparisons against > 0, 1 and -1 to use "test" instead of "cmp". > (*<maxmin>di3_doubleword): Likewise, allow general_operand > and enable on TARGET_CMOVE. > (peephole2): Convert clearing a register after a flag setting > instruction into an xor followed by the original flag setter. >
