https://bugs.kde.org/show_bug.cgi?id=417281
--- Comment #9 from Andreas Arnez <ar...@linux.ibm.com> --- (In reply to Julian Seward from comment #8) > For the NEVER case, it might be more "symmetrical" in relation to > the ALWAYS case, to say that it modifies dst, rather than saying > nothing. (I know it modifies it with the same value). Then > in effect the code says: > > NEVER= read dst, write dst; > ALWAYS = read src, write dst The rationale here was that NEVER results in no s390x instruction being emitted, so nothing is actually read or written. > although I think the absolute safest thing would be to put an assertion > in the construction for this insn to disallow NEVER and ALWAYS, since they > are degenerate cases, and I assume will never occur in practice. It seems that s390_isel_cc can at least theoretically yield NEVER or ALWAYS (in case of an Int1 constant, Ico_U1), so I guess I feel more comfortable with leaving support for that in right now. Unless it's guaranteed that Ico_U1 can't survive until isel? Of course, we could also handle these cases specially instead of always creating a conditional move. Perhaps I'll look into that later, but I prefer to do that independently from this bug. > Second point is .. are there any other cond-move insn variants? > FP, Vector etc? Not yet, but I guess I'll have to add them in order to fix the remaining "grail" fails on s390x. > +1 to land with any of the above changes you think are good (including none). OK, thanks for looking into this! -- You are receiving this mail because: You are watching all bug changes.
