[llvm-dev] [RFC] A new multidimensional array indexing intrinsic

[Kaylor, Andrew via llvm-dev]

OK, I think we're on the same page now. 

Do we really have code that uses the suffix of an intrinsic for semantic information? That seems like a bad idea. My understanding was that the suffix was just there to provide a unique name and the function signature took care of everything else.

Implementing an intrinsic that later got promoted to a new instruction might be a possibility. Does anyone have a sense for how far out typeless pointers are?

Can someone put together some concrete examples that fully describe how this would look in terms of both the intrinsic proposal and the GEP extension you worked out with Johannes?

Thanks,
Andy

-----Original Message-----
From: Michael Kruse <llvmdev at meinersbur.de> 
Sent: Monday, July 22, 2019 6:14 PM
To: Kaylor, Andrew <andrew.kaylor at intel.com>
Cc: Michael Kruse <llvm at meinersbur.de>; LLVM Developers Mailing List <llvm-dev at lists.llvm.org>; Tobias Grosser <tobias.grosser at inf.ethz.ch>; SAHIL GIRISH YERAWAR <cs15btech11044 at iith.ac.in>; Michael Ferguson <mferguson at cray.com>
Subject: Re: [llvm-dev] [RFC] A new multidimensional array indexing intrinsic

Hi,

I think I understand what the problem is. The return type will also be an untyped pointer, just like GEP. However, GEP needs to know what the size of one element is. Like it is now with overloadable intrinsics, we might derive it from the suffix. Another solution is that we pass the element and array sizes in bytes, instead of multiples of the element size. As a third options, we might change and auto-upgrade the intrinsic to a proper instruction when the change comes.

Michael


Am Mo., 22. Juli 2019 um 20:14 Uhr schrieb Kaylor, Andrew via llvm-dev
<llvm-dev at lists.llvm.org>:
>
> I don't think the return type has anything to do with what I was asking about. Perhaps seeing a concrete, fully-legal IR representation of what's being proposed would help.
>
> Here's a best guess, switching the indexed base type to a non-integer for illustration purposes:
>
> %arrayidx = call i64 
> @llvm.multidim.array.index.i64.p0f64.i64.i64.i64.i64 double* %A, i64 
> %str_1, i64 %idx_1, i64 %str_2, i64 %idx_2
>
> According to the RFC, that would get lowered to this:
>
>   %mul1 = mul nsw i64 %str_1, %idx_1
>   %mul2 = mul1 nsw i64 %str_2, %idx_2
>   %total = add nsw i64 %mul2, %mul1
>   %arrayidx = getelementptr inbounds double, double* %A, i64 %total, 
> !multidim !1
>
> The problem I'm having is that the source element type in the GEP instruction in the lowering can only be inferred from the pointer type, which is going away at some point. When pointers become typeless, the call will look something like this:
>
> %arrayidx = call i64 @llvm.multidim.array.index.i64.p0.i64.i64.i64.i64 
> void* %A, i64 %str_1, i64 %idx_1, i64 %str_2, i64 %idx_2
>
> Do you see what I'm saying? Have I misunderstood something?