[all-commits] [llvm/llvm-project] b98f90: GlobalISel: Restructure argument lowering loop in ...

[Matt Arsenault via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: b98f902f1877c3d679f77645a267edc89ffcd5d6
      https://github.com/llvm/llvm-project/commit/b98f902f1877c3d679f77645a267edc89ffcd5d6
  Author: Matt Arsenault <Matthew.Arsenault at amd.com>
  Date:   2020-07-22 (Wed, 22 Jul 2020)

  Changed paths:
    M llvm/include/llvm/CodeGen/GlobalISel/CallLowering.h
    M llvm/lib/CodeGen/GlobalISel/CallLowering.cpp
    M llvm/lib/Target/AArch64/GISel/AArch64CallLowering.cpp
    M llvm/lib/Target/AMDGPU/AMDGPUCallLowering.cpp

  Log Message:
  -----------
  GlobalISel: Restructure argument lowering loop in handleAssignments

This was structured in a way that implied every split argument is in
memory, or in registers. It is possible to pass an original argument
partially in registers, and partially in memory. Transpose the logic
here to only consider a single piece at a time. Every individual
CCValAssign should be treated independently, and any merge to original
value needs to be handled later.

This is in preparation for merging some preprocessing hacks in the
AMDGPU calling convention lowering into the generic code.

I'm also not sure what the correct behavior for memlocs where the
promoted size is larger than the original value. I've opted to clamp
the memory access size to not exceed the value register to avoid the
explicit trunc/extend/vector widen/vector extract instruction. This
happens for AMDGPU for i8 arguments that end up stack passed, which
are promoted to i16 (I think this is a preexisting DAG bug though, and
they should not really be promoted when in memory).