search for: getactiondefinitionsbuild

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 for TypeIdx==1. Is it intentionally implemented this way? >> b) Is the plan to s...

...es. For example this particular question arose because we are seeing the following LLVM-IR, which we cannot legalize with our 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 th...

Hello, I am developing GlobalISel for MIPS. I have a few questions and observations about defining legality of generic instruction and also possible combining of instructions and artifacts in pre/post legalizer combiner or elsewhere (e.g. in some sort of instruction-select patterns). I look at legality as "If generic instruction can be selected into machine instruction, it is legal".

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