[llvm-bugs] [Bug 32560] New: GlobalISel AArch64: s16 FPR: Assertion failed: (OrigTy.getSizeInBits() == NewTy.getSizeInBits() && "Types with difference size cannot be handled by the default " "mapping")

[via llvm-bugs]

http://bugs.llvm.org/show_bug.cgi?id=32560

            Bug ID: 32560
           Summary: GlobalISel AArch64: s16 FPR: Assertion failed:
                    (OrigTy.getSizeInBits() == NewTy.getSizeInBits() &&
                    "Types with difference size cannot be handled by the
                    default " "mapping")
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: GlobalISel
          Assignee: unassignedbugs at nondot.org
          Reporter: ahmed.bougacha at gmail.com
                CC: llvm-bugs at lists.llvm.org

This:

define void @f(float %a, half* %p) {
  %tmp0 = fptrunc float %a to half
  store half %tmp0, half* %p
  ret void
}

crashes regbankselect, with:

Assertion failed: (OrigTy.getSizeInBits() == NewTy.getSizeInBits() && "Types
with difference size cannot be handled by the default " "mapping"), function
applyDefaultMapping
0  clang-5.0                0x0000000102bd129c
llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 60
1  clang-5.0                0x0000000102bd1819
PrintStackTraceSignalHandler(void*) + 25
2  clang-5.0                0x0000000102bcd6a9 llvm::sys::RunSignalHandlers() +
425
3  clang-5.0                0x0000000102bd1c92 SignalHandler(int) + 354
4  libsystem_platform.dylib 0x00007fffc9605b3a _sigtramp + 26
5  clang-5.0                0x00000001078a9730 char const*
parse_block_invoke<(anonymous namespace)::Db>(char const*, char const*,
(anonymous namespace)::Db&)::test + 56928
6  libsystem_c.dylib        0x00007fffc948a420 abort + 129
7  libsystem_c.dylib        0x00007fffc9451893 basename_r + 0
8  clang-5.0                0x0000000103d63f39
llvm::RegisterBankInfo::applyDefaultMapping(llvm::RegisterBankInfo::OperandsMapper
const&) + 1401
9  clang-5.0                0x0000000103d54c81
llvm::RegisterBankInfo::applyMapping(llvm::RegisterBankInfo::OperandsMapper
const&) const + 65
10 clang-5.0                0x0000000103d54bcb
llvm::RegBankSelect::applyMapping(llvm::MachineInstr&,
llvm::RegisterBankInfo::InstructionMapping const&,
llvm::SmallVectorImpl<llvm::RegBankSelect::RepairingPlacement>&) + 987
11 clang-5.0                0x0000000103d55030
llvm::RegBankSelect::assignInstr(llvm::MachineInstr&) + 880
12 clang-5.0                0x0000000103d5579d
llvm::RegBankSelect::runOnMachineFunction(llvm::MachineFunction&) + 1629
13 clang-5.0                0x0000000101baf0d1
llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 449


Because we don't support 16-bit mappings in FPR, so we try to map the G_STORE
to GPR, but end up with a 32-bit mapping (because there is no GPR16 mapping).

If we have to create a COPY to satisfy bank constraints (because the vreg we're
using was mapped to FPR earlier), we later fail when creating the COPY to apply
the mapping, as we're confused that an s32 mapping would have an s16 type.

We could relax the assert: it probably happens to work if we use the s16 type
(in the same way that our current "half-widening" legalized code will have s16
vregs mapped to s32 GPR).

We could also add an FPR16 mapping, but I suspect we'd have a problem
analoguous to PR32550: if there are FPR8/FPR16 mappings, but no GPR8/GPR16, we
could end up mapping s8/s16 G_LOAD/G_STORE to FPR.

We could also add a GPR16 mapping, to acknowledge the current half-widening
legalization.  If some of the instructions are going to be kept around as legal
at s16/s8, they should be fully supported by our mappings, not just happen to
work because we never attempt to fixup the mapping.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20170407/d18d56f3/attachment.html>