[llvm-dev] GlobalISel: Ambiguous intrinsic semantics problem

[Amara Emerson via llvm-dev]

> On Mar 11, 2019, at 4:28 PM, Eli Friedman <efriedma at quicinc.com> wrote:
> 
> I think it’s fair to say that overloading int vs. fp shouldn’t change the semantics of an operation.  Not sure where we would document it though… it’s sort of a meta-rule for constructing intrinsics, rather than a rule about any specific intrinsic.  I guess we could stick it into the paragraph on intrinsic overloading.
Yes, at least having some kind of documentation on what’s expected to work would be helpful.
>  
> That said, thinking about it a bit more, even if we fix the AArch64 intrinsic, you might run into a related issue eventually, though… specifically, on PowerPC, you’ll need to eventually figure out some way to distinguish fp128 intrinsics from ppc_fp128 intrinsics.
I think for those kinds of types, if they’re ever supported, we’d have to introduce distinct LLTs for them.

Amara
>  
> -Eli
>  
> From: aemerson at apple.com <aemerson at apple.com> 
> Sent: Monday, March 11, 2019 2:04 PM
> To: Matt Arsenault <arsenm2 at gmail.com>; Eli Friedman <efriedma at quicinc.com>
> Cc: llvm-dev <llvm-dev at lists.llvm.org>
> Subject: [EXT] Re: [llvm-dev] GlobalISel: Ambiguous intrinsic semantics problem
>  
> 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 <mailto: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/20190314/5bbd3802/attachment.html>