[PATCH] D42424: [InstCombine] Allow common type conversions to i8/i16

[Krzysztof Parzyszek via Phabricator via llvm-commits]

kparzysz added a comment.

In https://reviews.llvm.org/D42424#990024, @spatel wrote:

> So let me adjust the question: if source code was written in a way that this new variant of IR with truncs was already created (independent of this patch), then we're already failing to match, right? Or is there something that guarantees that that pattern is not created from source in the first place?


The motivating source had short types (uint8_t and uint16_t) or equivalent, if I remember correctly, and the passes running prior to LIR "legalized" the types to i32.  The pattern matching code was written to detect a loop that does polynomial multiplication and polynomial division (with a remainder).  Originally it was matching the code that was generated from the sources at the time (and the operating type was i32 after extensions).  Over time, changes in combining caused it to fail without us noticing (we didn't have that testcase, just something with a pre-generated IR going directly to the LIR pass).  Due to the complexity of the LIR code, it was left alone, and a pre-processing step was added to it to convert the IR back to the form that it looked for, essentially undoing the combiner's changes.  This was done on a "local copy" of the IR, so to speak, so it didn't really undo it for the rest of the passes.  If the match succeeded, the loop would go away, otherwise, the IR would stay (and the "local copy" would be deleted).


https://reviews.llvm.org/D42424