Page MenuHomePhabricator

GlobalISel: Use DAG call lowering infrastructure in a more compatible way

Authored by arsenm on Apr 24 2021, 9:07 AM.



GlobalISel: Use DAG call lowering infrastructure in a more compatible way

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

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

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

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

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.

Diff Detail

Event Timeline

arsenm created this revision.Apr 24 2021, 9:07 AM
arsenm requested review of this revision.Apr 24 2021, 9:07 AM
Herald added a project: Restricted Project. · View Herald TranscriptApr 24 2021, 9:07 AM
Herald added a subscriber: wdng. · View Herald Transcript
arsenm updated this revision to Diff 340290.Apr 24 2021, 9:14 AM

Cleanup variable names and drop unused overload

foad added a subscriber: foad.Apr 26 2021, 1:45 AM
paquette added inline comments.May 4 2021, 9:43 AM

Missing )


Commented-out param?


Why is SrcTy.isPointer() == DstTy.isPointer() not allowed?

arsenm added inline comments.May 4 2021, 10:45 AM

The whole point of the function is to hack around using LLTs on top of the MVT infrastructure. One of these types is derived from an MVT and therefore can never be a pointer. If both were pointers, they would have to have the same address space to use a plain copy, and would be handled by the early exit for exact type match

aemerson added inline comments.May 4 2021, 10:57 AM

I think because to cast between different pointer address spaces you need an explicit G_ADDRSPACE_CAST.


This is identical to the other override. Can you factor it out?


Why is this changing?

arsenm added inline comments.May 4 2021, 11:00 AM

According to the tablegen calling convention definition, <4 x s32> is supposed to be bitcasted to <2 x s64>. This was silently ignoring this before and directly assigning the physreg to the result type

aemerson added inline comments.May 4 2021, 11:30 AM

Ah right, this is <4 x f32> not <4 x i32>.

arsenm updated this revision to Diff 342864.May 4 2021, 2:23 PM
arsenm marked 3 inline comments as done.

Address comments

aemerson accepted this revision.May 5 2021, 11:41 AM
This revision is now accepted and ready to land.May 5 2021, 11:41 AM

This seems to have broken the following code for AArch64, could you take a look?

target datalayout = "e-m:o-i64:64-i128:128-n32:64-S128"
target triple = "arm64e-apple-ios14.0.0"

declare <3 x float> @bar(float)

define void @foo(float %a, float %b) {
  %call = call <3 x float> @bar(float undef)
  ret void

This seems to have broken the following code for AArch64, could you take a look?

target datalayout = "e-m:o-i64:64-i128:128-n32:64-S128"
target triple = "arm64e-apple-ios14.0.0"

declare <3 x float> @bar(float)

define void @foo(float %a, float %b) {
  %call = call <3 x float> @bar(float undef)
  ret void

I went ahead and committed a fix anyway in 80c534a8f97fef050ebbe3411413018abd2ca2ae. A post-commit check is welcome though.