search for: llts

...nored and silently converted to s32. We could get similar result if we have:   getActionDefinitionsBuilder(G_SELECT)       .legalFor({{s32, s32}, {s64, s32}, {p0, s32}})       .clampScalar(0, s32, s64)       .clampScalar(1, s32, s32)       .widenScalarToNextPow2(0); And in this case sizes of LLTs and register classes would be the same. Implementation for G_ICMP on AArch64 is very similar to second described option for G_SELECT. Is there a reason for different implementation of G_SELECT and G_ICMP on AArch64? Are there some general ruses to determine which of the two given options is bett...

Matt: that’s fair. We’re generally apprehensive of option 2 as well. Eli: Yes, currently we believe that aarch64.neon.addp is the only arm64 one affected, but we don’t know how prevalent this is on other targets. Splitting it is certainly possible combined with the autoupgrader. If disambiguating the intrinsics is the preferred solution, then I think we should also have the langref also specify

I don’t think bfloat should be handled this way. What Amara is suggesting is an optimization, i.e., if we drop the information we are still correct. With bfloat, if we do an operation on float16 instead of bfloat16 this is a correctness problem. So that means that either we need to have new opcodes for bfloat or we need to carry around the floating point type in MIR. I think it would be more

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".