[llvm-dev] GlobalISel: Ambiguous intrinsic semantics problem

[Amara Emerson via llvm-dev]

Hi GlobalISel interested parties,

A recent bug report (https://bugs.llvm.org/show_bug.cgi?id=40968) on AArch64 exposed a problem with our modeling of intrinsic semantics when dealing with type overloaded calls. The crux of the matter is that because GlobalISel’s LowLevelTypes only carry size and vector layout information, and not any information about whether a type is integer or fp, we lose information during IR translation of type overloaded intrinsics.

Most of the time, we don’t run into this issue because the generic opcodes distinguish between fp and int operations, and for most intrinsics the regbank can normally disambiguate the operation (e.g. the source operands are assigned either gpr or fpr banks). However, this isn’t enough in the case of vectors on arm64, which can contain both fp and int elements, and if target intrinsics have been defined to use their type overloading to determine the semantics, then we can select the wrong instruction.

Some approaches to fix this:
We can try to propagate the missing information through the G_INTRINSIC instruction. We could do this either through some additional storage in MachineInstr, or through an additional operand to store type information (a single bit per operand should suffice). These come with the drawbacks of either increasing the size of MachineInstr, or breaking existing code that deals with intrinsics by adding a new operand somewhere.
Change the LLT types in GISel to distinguish between fp and integer types. This seems like the most natural fix in that we match the IR type system more closely, but it also has very significant impacts on the existing GISel codebase. An fp “flag” on a type that only affects types used by intrinsics sounds tempting, but it doesn’t work when we have to propagate those types through other users and copies. This means that if we decide to add an fp variant, we have to change the entire design of GISel to now handle both integer and fp types, whereas before we only cared about their size/vector structure.
Somehow do target intrinsic translation so that any ambiguous operations get split into sub-intrinsics to ensure they’re distinct. This approach has the disadvantages of requiring manual handling of these intrinsics, and that means that we can’t handle any ambiguous intrinsics automatically through the current pattern importer or the future GISel-native pattern selector. We could potentially detect these by re-using the importer to do analysis and emit warnings when two different output instructions map to the same input pattern. This is more of a workaround rather than an actual fix of the underlying problem.


Any strong preferences for a route forward?

Thanks,
Amara
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190311/7513afec/attachment.html>