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

[Daniel Sanders via llvm-dev]

Hi Dominik,

I'm way behind on llvm-dev at the moment but I'm slowly catching up and came across your post.

> On 24 Mar 2020, at 09: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.

I agree that this is exploiting internal knowledge. clampScalar() (and the underlying narrowScalar()) is supposed to do the right thing by itself. It can be useful to direct the legalizer to make something less-legal before converging on a legal result but in this case I think you're working around a bug in narrowScalar().

It sounds like you're hitting cases where narrowScalar either gives up or emits invalid code. Either way, it's a bug as (for the scalar case from your example) it's intended to be able to handle any scalar to any smaller scalar. It's technically valid for narrowScalar to emit an intermediate widen using a different operation. That's something that has to be done very carefully though because of the risk of infinite loops where the ruleset and the implementation conflict. That said, I'd expect it to be safe w.r.t infinite loops if the widen is done with G_ANYEXT because G_ANYEXT/G_TRUNC have some mandatory legality and we already rely on being able to freely widen/narrow with them.

> 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)?

The big danger of this is that you end up with infinite loops in the ruleset. For the case in your example you're safe as long as later rules never produce a non-power-of-2 type.

> Would be great to get some feedback so we know whether we can start adding support for some instructions or if we just need to rewrite some of our legalization rules using the internal knowledge.
> 
> Regards,
> 
> Dominik
> 
> -- 
> ----------------------------------------------------------------------
> Dominik Montada                   Email: dominik.montada at hightec-rt.com
> HighTec EDV-Systeme GmbH          Phone: +49 681 92613 19
> Europaallee 19                    Fax:   +49-681-92613-26
> D-66113 Saarbrücken               WWW: http://www.hightec-rt.com
> 
> Managing Director: Vera Strothmann
> Register Court: Saarbrücken, HRB 10445, VAT ID: DE 138344222
> 
> This e-mail may contain confidential and/or privileged information. If
> you are not the intended recipient please notify the sender immediately
> and destroy this e-mail. Any unauthorised copying, disclosure or
> distribution of the material in this e-mail is strictly forbidden.
> ---
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev