forked from OSchip/llvm-project
fa0b93b5a0
Unfortunately the current call lowering code is built on top of the legacy MVT/DAG based code. However, GlobalISel was not using it the same way. In short, the DAG passes legalized types to the assignment function, and GlobalISel was passing the original raw type if it was simple. I do believe the DAG lowering is conceptually broken since it requires picking a type up front before knowing how/where the value will be passed. This ends up being a problem for AArch64, which wants to pass i1/i8/i16 values as a different size if passed on the stack or in registers. The argument type decision is split across 3 different places which is hard to follow. SelectionDAG builder uses getRegisterTypeForCallingConv to pick a legal type, tablegen gives the illusion of controlling the type, and the target may have additional hacks in the C++ part of the call lowering. AArch64 hacks around this by not using the standard AnalyzeFormalArguments and special casing i1/i8/i16 by looking at the underlying type of the original IR argument. I believe people have generally assumed the calling convention code is processing the original types, and I've discovered a number of dead paths in several targets. x86 actually relies on the opposite behavior from AArch64, and relies on x86_32 and x86_64 sharing calling convention code where the 64-bit cases implicitly do not work on x86_32 due to using the pre-legalized types. AMDGPU targets without legal i16/f16 have always used a broken ABI that promotes to i32/f32. GlobalISel accidentally fixed this to be the ABI we should have, but this fixes it so we're using the worse ABI that is compatible with the DAG. Ideally we would fix the DAG to match the old GlobalISel behavior, but I don't wish to fight that battle. A new native GlobalISel call lowering framework should let the target process the incoming types directly. CCValAssigns select a "ValVT" and "LocVT" but the meanings of these aren't entirely clear. Different targets don't use them consistently, even within their own call lowering code. My current belief is the intent was "ValVT" is supposed to be the legalized value type to use in the end, and and LocVT was supposed to be the ABI passed type (which is also legalized). With the default CCState::Analyze functions always passing the same type for these arguments, these only differ when the TableGen part of the lowering decide to promote the type from one legal type to another. AArch64's i1/i8/i16 hack ends up inverting the meanings of these values, so I had to add an additional hack to let the target interpret how large the argument memory is. Since targets don't consistently interpret ValVT and LocVT, this doesn't produce quite equivalent code to the initial DAG lowerings. I've opted to consistently interpret LocVT as the in-memory size for stack passed values, and ValVT as the register type to assign from that memory. We therefore produce extending loads directly out of the IRTranslator, whereas the DAG would emit regular loads of smaller values. This will also produce loads/stores that are wider than the argument value if the allocated stack slot is larger (and there will be undef padding bytes). If we had the optimizations to reduce load/stores based on truncated values, this wouldn't produce a different end result. Since ValVT/LocVT are more consistently interpreted, we now will emit more G_BITCASTS as requested by the CCAssignFn. For example AArch64 was directly assigning types to some physical vector registers which according to the tablegen spec should have been casted to a vector with a different element type. This also moves the responsibility for inserting G_ASSERT_SEXT/G_ASSERT_ZEXT from the target ValueHandlers into the generic code, which is closer to how SelectionDAGBuilder works. I had to xfail an x86 test since I don't see a quick way to fix it right now (I filed bug 50035 for this). It's broken independently of this change, and only triggers since now we end up with more ands which hit the improperly handled selection pattern. I also observed that FP arguments that need promotion (e.g. f16 passed as f32) are broken, and use regular G_TRUNC and G_ANYEXT. TLDR; the current call lowering infrastructure is bad and nobody has ever understood how it chooses types. |
||
---|---|---|
.. | ||
arm-call-lowering.ll | ||
arm-instruction-select-cmp.mir | ||
arm-instruction-select-combos.mir | ||
arm-instruction-select.mir | ||
arm-irtranslator.ll | ||
arm-isel-divmod.ll | ||
arm-isel-fp.ll | ||
arm-isel-globals-pic.ll | ||
arm-isel-globals-ropi-rwpi.ll | ||
arm-isel-globals-static.ll | ||
arm-isel.ll | ||
arm-legalize-binops-neon.mir | ||
arm-legalize-binops.mir | ||
arm-legalize-bitcounts.mir | ||
arm-legalize-casts.mir | ||
arm-legalize-cmp.mir | ||
arm-legalize-consts.mir | ||
arm-legalize-control-flow.mir | ||
arm-legalize-divmod.mir | ||
arm-legalize-exts.mir | ||
arm-legalize-fp.mir | ||
arm-legalize-globals.mir | ||
arm-legalize-load-store.mir | ||
arm-legalize-select.mir | ||
arm-legalize-vfp4.mir | ||
arm-legalizer.mir | ||
arm-param-lowering.ll | ||
arm-regbankselect.mir | ||
arm-select-copy_to_regclass-of-fptosi.mir | ||
arm-select-globals-pic.mir | ||
arm-select-globals-ropi-rwpi.mir | ||
arm-select-globals-static.mir | ||
arm-unsupported.ll | ||
irtranslator-varargs-lowering.ll | ||
pr35375.ll | ||
select-clz.mir | ||
select-dbg.mir | ||
select-fp-const.mir | ||
select-fp.mir | ||
select-neon.mir | ||
select-pkhbt.mir | ||
select-pr35926.mir | ||
select-revsh.mir | ||
thumb-instruction-select-cmp.mir | ||
thumb-isel-globals-pic.ll | ||
thumb-isel-globals-ropi-rwpi.ll | ||
thumb-isel-globals-static.ll | ||
thumb-select-arithmetic-ops.mir | ||
thumb-select-br.mir | ||
thumb-select-casts.mir | ||
thumb-select-exts.mir | ||
thumb-select-globals-pic.mir | ||
thumb-select-globals-ropi-rwpi.mir | ||
thumb-select-globals-static.mir | ||
thumb-select-imm.mir | ||
thumb-select-load-store.mir | ||
thumb-select-logical-ops.mir | ||
thumb-select-phi.mir | ||
thumb-select-select.mir | ||
thumb-select-shifts.mir |