
<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi,<div class=""><br class=""></div><div class="">I’m trying to handle some vector operations with splitting/scalarization and keep running into similar sorts of issues which are making me question the intended function of the various legalization operations (particularly G_MERGE_VALUES/G_UNMERGE_VALUES, but also G_EXTRACT/G_INSERT and conversion instructions) and what the contract between the legalizer and selector actually is.</div><div class=""><br class=""></div><div class="">For scalar values, things seem clearer, but I’m still confused. The AArch64 selector code seems content to allow strange sized values in the source of G_EXTRACT/G_SEXT etc, and then just set the register class as the type information isn’t really needed anymore. However, it also defines a more restricted set of legal types, but the legalizations are not implemented. Similarly quite a lot of legalization rules defined for merge/unmerge (an ~88 line block), but again none of these legalizations seem to actually be implemented. For example, it specifies that vector types with < 8-bit elements should be scalarized.</div><div class=""><br class=""></div><div class="">For vectors it’s less clear to me what to do. For example, I’ve looked at implementing widenScalar for G_UNMERGE_VALUES. This in turn ends up defined as an extend of the vector type, which in turn will be implemented with another G_UNMERGE_VALUES which needs to be split and it’s a legalization loop producing an infinite number of instructions. It’s also not really clear to me what it means to scalarize a G_UNMERGE_VALUE, other than to rewrite the def instruction of the source to produce scalar values. Rewriting as a series of extract_vector_elt on the source just runs into the same issue that nothing actually is dealing with the problematic vector type. Is this something the legalizer should really be doing? For AMDGPU essentially any vector type needs to be eliminated (especially for something like an s1 vector) but it’s not clear to me how this should really happen if legalization just keeps moving the vector type to a different unmerge source.</div><div class=""><br class=""></div><div class="">My questions are :</div><div class=""><ol class=""><li class="">What is AArch64 doing with all of its legalization rules when they don’t seem to actually be implemented?</li><li class="">Is the target selector supposed to be responsible for handling G_UNMERGE_VALUES/G_MERGE_VALUES/G_EXTRACT/G_INSERT/G_SEXT/G_ZEXT/G_ANYEXT for any strange type source, assuming the extra high bits over the LLT type are undefined or appropriately extended?</li><li class="">For vectors, is any arbitrary vector only supposed to be legalized to a certain number of elements, and the target is supposed to treat this as N registers with possibly undefined high bits in NumRegBits - TypeScalarSize?</li><li class="">Should the legalizer for some of these operations really be triggering legalization of the def instruction of the input instead?</li></ol></div><div class="">-Matt</div></body></html>