SDIV >128bit, DAG->DAG error in LegalizeIntegerTypes

[Quuxplusone]

Bugzilla Link	PR17406
Status	NEW
Importance	P normal
Reported by	edA-qa mort-ora-y (eda-qa@disemia.com)
Reported on	2013-09-29 23:02:02 -0700
Last modified on	2020-04-29 02:16:59 -0700
Version	trunk
Hardware	PC Linux
CC	chfast@gmail.com, efriedma@quicinc.com, llvm-bugs@lists.llvm.org, llvm-dev@redking.me.uk
Fixed by commit(s)
Attachments
Blocks
Blocked by
See also	PR45649

I'm getting the following error when trying to SDIV integers greater
than 128bit (on an AMD64 target).

LegalizeIntegerTypes.cpp:2047: void
llvm::DAGTypeLegalizer::ExpandIntRes_SDIV(llvm::SDNode*, llvm::SDValue&,
llvm::SDValue&): Assertion `LC != RTLIB::UNKNOWN_LIBCALL && "Unsupported
SDIV!"' failed.
Stack dump:
0.      Running pass 'X86 DAG->DAG Instruction Selection' on function
'@_entry'

However, not all SDIV on such integers fails, the below works:

@a = global i200 undef
@b = global i64 undef

define void @_entry() {
entry:
  store i200 200, i200* @a
  %0 = load i200* @a
  %1 = load i200* @a
  %2 = sdiv i200 %0, %1
  %3 = trunc i200 %2 to i64
  store i64 %3, i64* @b
  %4 = load i64* @b
  call void @trace_integer(i64 %4)
  ret void
}

Yet with a simple addition (the same SDIV) it fails:

define void @_entry() {
entry:
  store i200 200, i200* @a
  %0 = load i200* @a
  %1 = load i200* @a
  %2 = sdiv i200 %0, %1
  %3 = trunc i200 %2 to i64
  store i64 %3, i64* @b
  %4 = load i200* @a
  %5 = load i200* @a
  %6 = sdiv i200 %4, %5
  store i200 %6, i200* @a
  ret void
}

This is on the LLVM 3.3 release (it also happens on 3.2, the reason I updated).
As it appears all integer sizes are intended to be supported I assume this is a
defect.

[Quuxplusone]

We should print a better error message... but this is definitely not supported: there is no reasonable way for LLVM to actually generate code for this construct.

[Quuxplusone]

I think updating the docs might be enough (the IR Reference Guide). It doesn't seem to place restrictions on the use of larger integer types: since add, sub, mul, bit ops, and comparisons, are all supported. But yeah, if I look at the algorithm for multi-word division I can see why you might not wish to support it at the IR level. I'll have to add it as a library routine at a higher level.