Tim Northover via llvm-dev
2019-Jul-24 20:13 UTC
[llvm-dev] [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/D64203Yep, 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.
Jeff Hammond via llvm-dev
2019-Jul-24 23:14 UTC
[llvm-dev] [RFC] A new multidimensional array indexing intrinsic
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>
Doerfert, Johannes via llvm-dev
2019-Jul-25 03:39 UTC
[llvm-dev] [RFC] A new multidimensional array indexing intrinsic
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>
Tim Northover via llvm-dev
2019-Jul-25 07:59 UTC
[llvm-dev] [RFC] A new multidimensional array indexing intrinsic
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.
Michael Kruse via llvm-dev
2019-Jul-25 14:20 UTC
[llvm-dev] [RFC] A new multidimensional array indexing intrinsic
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
David Greene via llvm-dev
2019-Jul-25 15:40 UTC
[llvm-dev] [RFC] A new multidimensional array indexing intrinsic
"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
Chris Lattner via llvm-dev
2019-Jul-28 22:33 UTC
[llvm-dev] [RFC] A new multidimensional array indexing intrinsic
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>