Richard Henderson wrote: > On 11/06/2014 05:10 PM, Ulrich Weigand wrote: > >>> + /* For s390, CC REG is general_operand. But cstorecc4 > >>> only > >>> + handles CCZ1, which can not handle others like CCU. > >>> */ > >>> + || GET_MODE_CLASS (GET_MODE (XEXP (cond, 0))) == MODE_CC); > >>> > >> > >> I'd like to know more about this. This seems like a mistake in the > >> backend. > > > > We do indeed allow the CC register as general_operand, since it has a > > register class of CC_REGS. > > I rather meant that cstorecc4 only handles some MODE_CC, not that > CC is a general_operand, that seems questionable.
Well, it's only for CCZ1mode that we can implement cstorecc4 using a simple "IPM / shift" sequence. In order to handle generic MODE_CC modes, we'd have to implement a mask check, something like "IPM / shift / load immediate / shift / and-immediate". This will usually be slower than then default branch sequence generated by the middle end. [ On z196 and more recent machines, we already use LOCR to select one of two immediates (in registers), generated via the mov<mode>cc expander; this can handle generic MODE_CC modes. ] But no matter the rationale, I still don't see what the original problem is; the pattern describes the mode it can support -- shouldn't this be enough for the middle end to know whether it is available, without requiring any further special-case checks? Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain ulrich.weig...@de.ibm.com
