llvm dev - Jul 2019 - [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?

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?

Am Di., 23. Juli 2019 um 17:16 Uhr schrieb Kaylor, Andrew
<andrew.kaylor at intel.com>:
> 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.
I agree that this is also not my preferred option, but more an
illustration that the information is not lost. If, for any reason, we
would still use an intrinsics for this purpose, we can pass the byte
of the element type as an argument. In any case, I don't think this is
a critical issue.

> 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?
I haven't seen any discussion about this for a long time and I would
not count on that this change will be made in the foreseeable future.
Similar to the idea of basic block arguments instead of PHI nodes.

> 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?
The closest we have is the RFC document
(https://github.com/bollu/llvm-multidim-array-indexing-proposal/blob/master/RFC.md).
We are in the RFC phase to explore the problem and design space. Do
you have any concrete questions you would like the be answered?

Michael