[llvm-dev] GlobalISel: Ambiguous intrinsic semantics problem

[Amara Emerson via llvm-dev]

Matt: that’s fair. We’re generally apprehensive of option 2 as well.

Eli: Yes, currently we believe that aarch64.neon.addp is the only arm64 one affected, but we don’t know how prevalent this is on other targets. Splitting it is certainly possible combined with the autoupgrader.

If disambiguating the intrinsics is the preferred solution, then I think we should also have the langref also specify that there’s no guarantee of correction codegen *solely* on the basis of int/fp type overloading for intrinsics. What do you think?

Amara

> On Mar 11, 2019, at 1:23 PM, Matt Arsenault <arsenm2 at gmail.com> wrote:
> 
> 
> 
>> On Mar 11, 2019, at 3:30 PM, Amara Emerson via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>> 
>> Hi GlobalISel interested parties,
>> 
>> A recent bug report (https://bugs.llvm.org/show_bug.cgi?id=40968 <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.
> 
> I’m pretty strongly opposed to #2. I think the more relaxed type system is one of the advantages over SelectionDAG, and want to avoid the mess of bitcasts we have to insert now to satisfy the artificial type constraints. The original intrinsic seems misspecified to me, and should be spilt into separate FP/int versions.
> 
> -Matt

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190311/64bc219b/attachment.html>