[llvm-dev] [GlobalISel] Narrowing uneven/non-pow-2 types

[Matt Arsenault via llvm-dev]

> On Mar 24, 2020, at 12:24, Dominik Montada via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> Hi all,
> 
> recently when working with GlobalISel we have often encountered cases in the legalizer where instructions could not be narrowed because the narrowing code relies on G_UNMERGE_VALUES and therefore requires the source type to be a multiple of the narrow type. Often times these instructions can be widened without any problem to a fitting type.
> 
> This has us writing legalization rules like `.widenScalarToNextPow2(0, /*MinSize*/ 32).maxScalar(0, s32)` instead of the much simpler `.clampScalar(0, s32 ,s32)`.
> 
> Although this works and has the desired effect, we feel like that such a rule requires internal knowledge of the legalizer, which can change at any point in the future. Ideally we would only want to say `clampScalar` and let the legalizer handle the rest, even if it requires extending the type before it can be narrowed.

Being able to specify the order of specific legalization steps is pretty useful, and one area I found frustrating in SelectionDAG. For example, we do use custom lowering in some places to hack around the order that operation expansion and legalization is done. In this particular case, another helper may be useful, since forcing a power of 2 and bounding the size are two distinct constraints.

> 
> We were now wondering if such a behavior in the legalizer is even desired? I.e. that an instruction is extended to an easier-to-handle type even though narrowing was requested (as long as the narrowing is done in the end)?


I would need more context on this question, and what specifically you are hitting. The current set of implemented legalization rules is fairly incomplete, and not all operations use a consistent strategy

-Matt