search for: g_lshr

Hi Daniel, On 13.09.2018. 19:32, Daniel Sanders wrote: > Could you clarify what you mean here? The new legalizer info can > define this with: >     getActionDefinitionsBuilder(G_SELECT).clampScalar(1, s32, s32) > so I'm guessing you mean that code to mutate the G_SELECT is currently > missing Yes, LegalizerHelper::widenScalar widens only TypeIdx==0, it doesn't do that

...ur current legalization rules:     %6 = zext i32 %5 to i33     %7 = zext i32 %0 to i33     %8 = mul i33 %6, %7     %9 = lshr i33 %8, 1     %10 = trunc i33 %9 to i32   getActionDefinitionsBuilder(G_MUL)       .legalFor({s32})       .clampScalar(0, s32, s32);   getActionDefinitionsBuilder(G_LSHR)       .legalFor({{s32, s32}})       .clampScalar(1, s32, s32)       .clampScalar(0, s32, s32); We would be able to legalize the above code if we just add a widenScalarToNextPow2 before the clampScalar in both cases. However we only know that this will work because we looked at the narrowing...

...xpress -- at least with the 'dag' type it's trivial. Yeah, I went off on a tangent a bit :-). For your example: Yes, there's only one inst for each multiclass instantiation so it's simple. For the tangent I was on, consider: %0 = G_CONSTANT iN %x %1 = G_CONSTANT iN %y %2 = G_LSHR %a, %x %3 = G_LSHR %1, %y => %0 = G_CONSTANT iN %z # z = x+y %1 = G_LSHR %a, %0 and: %0 = G_CONSTANT iN %x %1 = G_CONSTANT iN %y %2 = G_ASHR %a, %x %3 = G_ASHR %1, %y => %0 = G_CONSTANT iN %z # z = x+y %1 = G_ASHR %a, %0 and: %0 = G_CONSTANT iN %x %1 = G_CONSTANT iN %y %2 = G_SH...

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

Thanks Nicolai! > On Nov 9, 2018, at 02:55, Nicolai Hähnle <nhaehnle at gmail.com> wrote: > > Hi Daniel, > > Lots of good stuff in there! I especially like the design for specifying out-of-line predicates. I have a couple of small comments and one major one below. > > > On 09.11.18 02:42, Daniel Sanders via llvm-dev wrote: >> _Passing arbitrary data from