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

Hi all,

On Wed, 24 Jul 2019 at 16:14, Michael Kruse via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> Mmmh, looks like Tim Northover is actively working on typeless/opaque
> pointers, e.g. https://reviews.llvm.org/D64203
Yep, I'm spending as much time as I can on the project. I think
there's not really much chance that it'll be required in this cycle
(i.e. when we fork in ~Jan pointers will be distinct IMO).

On intrinsics as they affect opaque pointers, I took a look earlier
and didn't notice any target-independent ones that would need a
separate type parameter, but a couple of target-specific ones did.
Unless they were particularly anomalous and implementable by other
means, intrinsics will need to develop the ability to specify an
abstract "notable type" anyway.

Apart from all that, I'm pretty disappointed to see this as an
intrinsic though. GEP is such a fundamental part of addressing in LLVM
that bifurcating it into an intrinsic for either a language or an
analysis seems like we'd be papering over a language deficiency.

Cheers.

Tim.

On Wed, Jul 24, 2019 at 1:14 PM Tim Northover via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi all,
>
> On Wed, 24 Jul 2019 at 16:14, Michael Kruse via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > Mmmh, looks like Tim Northover is actively working on typeless/opaque
> > pointers, e.g. https://reviews.llvm.org/D64203
>
> Yep, I'm spending as much time as I can on the project. I think
> there's not really much chance that it'll be required in this cycle
> (i.e. when we fork in ~Jan pointers will be distinct IMO).
>
> On intrinsics as they affect opaque pointers, I took a look earlier
> and didn't notice any target-independent ones that would need a
> separate type parameter, but a couple of target-specific ones did.
> Unless they were particularly anomalous and implementable by other
> means, intrinsics will need to develop the ability to specify an
> abstract "notable type" anyway.
>
> Apart from all that, I'm pretty disappointed to see this as an
> intrinsic though. GEP is such a fundamental part of addressing in LLVM
> that bifurcating it into an intrinsic for either a language or an
> analysis seems like we'd be papering over a language deficiency.
>
I'm sorry if I am missing the joke, but multidimensional array support is a
profound and well-known deficiency in the C and C++ languages.

Jeff

> Cheers.
>
> Tim.
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>

-- 
Jeff Hammond
jeff.science at gmail.com
http://jeffhammond.github.io/
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190724/d4a92524/attachment.html>

On 07/24, Tim Northover via llvm-dev wrote:
> Apart from all that, I'm pretty disappointed to see this as an
> intrinsic though. GEP is such a fundamental part of addressing in LLVM
> that bifurcating it into an intrinsic for either a language or an
> analysis seems like we'd be papering over a language deficiency.
Agreed. I included some non-intrinsic solutions in the other mail for
this reason. Personally, I would prefer a type-system extension to make
multi-dimensional "inrange" GEPs for symbolic sized arrays a natural
GEP
extension. However, that solution is be the hardest to get right. If we
have enough dedicated people and no strong objections, we should give it
a try.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190725/504de17c/attachment.sig>

On Thu, 25 Jul 2019 at 00:14, Jeff Hammond <jeff.science at gmail.com>
wrote:
>> Apart from all that, I'm pretty disappointed to see this as an
>> intrinsic though. GEP is such a fundamental part of addressing in LLVM
>> that bifurcating it into an intrinsic for either a language or an
>> analysis seems like we'd be papering over a language deficiency.
>
> I'm sorry if I am missing the joke, but multidimensional array support
is a profound and well-known deficiency in the C and C++ languages.
I was referring to LLVM IR as the language. Sorry, too much time spent
in the backends (C? What's that?).

Cheers.

Tim.

Am Mi., 24. Juli 2019 um 16:13 Uhr schrieb Tim Northover
<t.p.northover at gmail.com>:
> Apart from all that, I'm pretty disappointed to see this as an
> intrinsic though. GEP is such a fundamental part of addressing in LLVM
> that bifurcating it into an intrinsic for either a language or an
> analysis seems like we'd be papering over a language deficiency.
What is your preferred approach?

Michael

"Doerfert, Johannes via llvm-dev" <llvm-dev at lists.llvm.org>
writes:
> On 07/24, Tim Northover via llvm-dev wrote:
>> Apart from all that, I'm pretty disappointed to see this as an
>> intrinsic though. GEP is such a fundamental part of addressing in LLVM
>> that bifurcating it into an intrinsic for either a language or an
>> analysis seems like we'd be papering over a language deficiency.
>
> Agreed. I included some non-intrinsic solutions in the other mail for
> this reason. Personally, I would prefer a type-system extension to make
> multi-dimensional "inrange" GEPs for symbolic sized arrays a
natural GEP
> extension. However, that solution is be the hardest to get right. If we
> have enough dedicated people and no strong objections, we should give it
> a try.
Are you suggesting dependent types in LLVM IR?  That would be really
useful not only for true multidimensional arrays and accesses, but also
things like vectorization with a runtime width (a la SVE and RISC-V).

Obviously it's a huge change.

If you have something else in mind, can youi elaborate?

I too would prefer this kind of thing use GEP if possible.

                        -David

On Jul 25, 2019, at 7:20 AM, Michael Kruse via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> Am Mi., 24. Juli 2019 um 16:13 Uhr schrieb Tim Northover
> <t.p.northover at gmail.com>:
…
Siddharth’s original RFC
<https://github.com/bollu/llvm-multidim-array-indexing-proposal/blob/master/RFC.md>
...
>> Apart from all that, I'm pretty disappointed to see this as an
>> intrinsic though. GEP is such a fundamental part of addressing in LLVM
>> that bifurcating it into an intrinsic for either a language or an
>> analysis seems like we'd be papering over a language deficiency.
> 
> What is your preferred approach?

+mlir mailing list, even though I generally hate cross posting.

Have you been following what is happening on the MLIR side of the world?  It
directly supports multi-dimensional arrays with both value and buffer semantics
(e.g. load
<https://github.com/tensorflow/mlir/blob/master/g3doc/LangRef.md#load-operation>,
store
<https://github.com/tensorflow/mlir/blob/master/g3doc/LangRef.md#store-operation>,
and DMA
<https://github.com/tensorflow/mlir/blob/master/g3doc/LangRef.md#dma_start-operation>
operations).  It is specifically focused on solving these sorts of problems, and
is the current proposed direction for the flang compiler IR
<https://github.com/flang-compiler/f18/blob/master/documentation/Investigating-FIR-as-an-MLIR-dialect.md>
(as well as a bunch of HPC applications that haven’t gone public yet).  Even if
it isn’t directly relevant to this work, it is worth checking out to see if some
of the ideas can be borrowed.

-Chris

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