On 10/19/23 13:46, Richard Sandiford wrote:
I'd be all for that. We've actually got a similar problem in Joern's ext-dce code that I'm working on. At least in that case I think we'll be able to enumerate how/why things are on the list if we still need it after the cleanup phase.+ /* Allow a wide range of operations and let the costing function decide + if the conversion is worth it later. */ + enum rtx_code code = GET_CODE (src); + if (!(CONSTANT_P (src) + || code == REG + || code == SUBREG + || code == ZERO_EXTEND + || code == SIGN_EXTEND + || code == NOT + || code == NEG + || code == PLUS + || code == MINUS + || code == AND + || code == IOR + || code == MULT + || code == ASHIFT + || code == ASHIFTRT + || code == NE + || code == EQ + || code == GE + || code == GT + || code == LE + || code == LT + || code == GEU + || code == GTU + || code == LEU + || code == LTU + || code == COMPARE)) return false;I'm nervous about lists of operations like these, for two reasons: (1) It isn't obvious what criteria are used to select the codes. (2) It requires the top-level code to belong to a given set, but it allows subrtxes of src to be arbitrarily complex. E.g. (to pick a silly example) a toplevel (popcount ...) would be rejected, but (plus (popcount ...) (const_int 1)) would be OK. Could we just remove this condition instead?
So I think the guidance on patch #2 would be to remove the list entirely if we can.
jeff
