pub static NAMES: &[(&str, &str, &str)]Expand description
A name a rule could be written at and deliberately is not, why, and the issue that puts it back.
The third list, and the one that is about a name rather than about an opcode or a width. An
opcode on GAPS has no lowering at any width and a width on WIDTHS has no names at all,
and neither of those can say that add is lowered at four widths and left alone at two.
This list used to be all of the narrow arithmetic. C promotes the operands of an arithmetic
operator to int before the operator is applied, so char a, b; a + b is an int addition of
two sign extended chars and there is no C program that asks the back end to add two bytes.
Rules were written at those names anyway, ahead of the pass that would reach them, and they sat
proved and never selected: tamnd/rucc#261 measured that and tamnd/rucc#368 took them out.
They are back, because the width narrowing pass in tamnd/rucc#375 is that caller and it
writes a byte add out of the truncation the assignment back to a char already was. The last
to come back were the divides, which narrow when the operands are zero extensions and, for
sign extensions, when the ranges rule out the most negative value over minus one.
So the list is empty, and it stays here for the next name somebody decides to leave out, since the report and the capability table both read it.