similar to: Writing loop transformations on the right representation is more productive

Am So., 12. Jan. 2020 um 20:07 Uhr schrieb Chris Lattner < clattner at nondot.org>: > The central idea is to use a modifiable loop tree -- similar to > LoopInfo -- as the primary representation. LLVM-IR is converted to a > loop tree, then optimized and finally LLVM-IR is generated again for > subtrees that are considered profitable. This is not a new concept, it > has already

Am Fr., 10. Jan. 2020 um 16:10 Uhr schrieb Renato Golin <rengolin at gmail.com>: > On Fri, 3 Jan 2020 at 11:27, Michael Kruse via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > 1. Candidate selection through cost function > > -------------------------------------------- > > Instead of needing to know which transformation is profitable before > >

Dear all, Could anyone help me with the following? DATA <- data.frame(rbind(c("Red1", 1, 1, 1), c("Blue1", 1, 1, 1), c("Red2", 1, 1, 1), c("Red3", 1, 1, 1))) colnames(DATA) <- c("A", "B","C", "D") #Option 1 DATA <- DATA[-2, ] #Same result I would like to achieve with Option 2 #Option 2 - I would like to do

Am Mi., 15. Jan. 2020 um 20:27 Uhr schrieb Chris Lattner < clattner at nondot.org>: > One you achieve consensus on data structure, there is the question of what >> IR to use within it. I would recommend starting with some combination of >> “existing LLVM IR operations + high level control flow representation”, >> e.g. parallel and affine loops. The key here is that

I haven't seen much about the round tables at the dev meeting, on the list or the web page, anyone keeping track of those? I propose we do the usual one for VPlan to see who is working on what in the future, and one on SVE, so that we can sync on what's missing for this stage (IR) and what's the priorities for the next stages. I'd also like to discuss transformations in MLIR,

Reply to Kiran Chandramohan: > You are welcome to participate, provide feedback and criticism to change the design as well as to contribute to the implementation. Thank you Kiran. > But the latest is what is there in the RFC in discourse. I have used this as reference for the response. > We did a study of a few constructs and clauses which was shared as mails to flang-dev and the

Please find the reply inline below On Sun, Feb 16, 2020 at 12:59 AM Mehdi AMINI <joker.eph at gmail.com> wrote: > > > On Sat, Feb 15, 2020 at 10:42 AM Vinay Madhusudan via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Reply to Kiran Chandramohan: >> >> > You are welcome to participate, provide feedback and criticism to >> change the

Hi, I have few questions / concerns regarding the design of OpenMP dialect in MLIR that is currently being implemented, mainly for the f18 compiler. Below, I summarize the current state of various efforts in clang / f18 / MLIR / LLVM regarding this. Feel free to add to the list in case I have missed something. 1. [May 2019] An OpenMPIRBuilder in LLVM was proposed for flang and clang frontends.

Thanks for the reply! It sounds like LLVM IR is being considered for optimizations in OpenMP constructs. There seems to be plans regarding improvement of LLVM IR Framework for providing things required for OpenMP / flang(?) Are there any design considerations which contain pros and cons about using the MLIR vs LLVM IR for various OpenMP related optimizations/ transformations? The latest RFC [

Am Mo., 27. Jan. 2020 um 22:06 Uhr schrieb Uday Kumar Reddy Bondhugula < uday at polymagelabs.com>: > Hi Michael, > > Although the approach to use a higher order in-memory abstraction like the > loop tree will make it easier than what you have today, if you used MLIR > for this representation, you already get a round trippable textual format > that is *very close* to your

Am Sa., 11. Jan. 2020 um 07:43 Uhr schrieb Renato Golin <rengolin at gmail.com >: > On Sat, 11 Jan 2020 at 00:34, Michael Kruse <llvmdev at meinersbur.de> wrote: > > Yes, as mentioned in the Q&A. Unfortunately VPlan is able to represent > > arbitrary code not has cheap copies. > > Orthogonal, but we should also be looking into implementing the cheap > copies

Am Do., 30. Jan. 2020 um 04:40 Uhr schrieb Uday Kumar Reddy Bondhugula <uday at polymagelabs.com>: > There are multiple ways regions in MLIR can be viewed, but the more relevant point here is you do have a loop tree structure native in the IR with MLIR. Regions in MLIR didn't evolve from modeling inlined calls - the affine.for/affine.if were originally the only two operations in MLIR

On Tue, Sep 10, 2019 at 1:40 PM David Greene via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> writes: > > > But perhaps more importantly, as Hal states clearly, is the need for > > an official specification, similar to the one for LLVM IR, as well as > > a formal document with the expected semantics into

Overall, I think it will be a good move. Maintenance wise, I'm expecting the existing community to move into LLVM (if not all in already), so I don't foresee any additional costs. Though, Hal's points are spot on... On Mon, 9 Sep 2019 at 18:47, Finkel, Hal J. via llvm-dev <llvm-dev at lists.llvm.org> wrote: > 3. As a specific example of the above, the current development

On Wed, Sep 11, 2019 at 1:54 PM David Greene <greened at obbligato.org> wrote: > Mehdi AMINI <joker.eph at gmail.com> writes: > > > Of course by its nature, MLIR doesn't lend itself to concrete semantic > >> descriptions, though I would expect the affine dialect (and others) to > >> have documentation on par with the LLVM IR. > > > > >

Am Mi., 15. Jan. 2020 um 03:30 Uhr schrieb Renato Golin <rengolin at gmail.com>: > > I see it as an advantage in respect of adoption: It can be switched on and off without affecting other parts. > > That's not necessarily true. > > If we do like Polly, it is, but then the ability to reuse code is very > low and the time spent converting across is high. If we want to

Status Update on VPlan ---- where we are currently, and what's ahead of us ==========================================================   Goal: ----- Extending Loop Vectorizer (LV) such that it can handle outer loops, via uplifting its infrastructure with VPlan. The goal of this status update is to summarize the progress and the future steps needed.   Background: ----------- This is related to

On 31 July 2018 at 21:10, David A. Greene via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> writes: > >> Hi David, >> >> Let me put the last two comments up: >> >>> > But we're trying to represent slightly different techniques >>> > (predication, vscale change) which need

On Wed, 15 Apr 2020 at 17:28, David Blaikie <dblaikie at gmail.com> wrote: > > opaque pointers don't exist in the IR yet - the goal is to reduce the places that use non-opacity of pointer types already/today and then opacify the existing pointer type, rather than introducing an opaque pointer type & having it concurrently with non-opaque pointer types. (though in retrospect

Sure, I'll summarize with respect to the criterion in the document: - Must be generally aligned with the mission of the LLVM project to advance compilers, languages, tools, runtimes, etc. CIRCT is a compiler which is built around LLVM/MLIR. We anticipate building code generation for ASIC and FPGA backends along with specialized accelerators, while leveraging existing LLVM backends for