search for: profiti

...ral idea in your opening paras, but let's go with this now that it's clearer to me. Indeed, red/green trees (or DAGs) are one one of the ideas to improve loop optimizations, but does justify its use by itself. They happen to be effectively necessary for others in the list (e.g. versioning, profitiability heuristic by cost function, etc...) and the reason why I think the same cannot be done with MLIR. In hindsight, I could have pointed this out more in the original RFC. Note that a hierarchical representation was not an explicit feature in the list. To convince me that MLIR is the better IR...

...a JIT, you can expand heavily biased calls to test the function pointer (as a validation) and do a direct call. Then you may be able to inline or IP-constant propagate the call site. The target of that call site might be input data based, in which case you cannot statically do these optimizations profitiably, and even profiling may blur the fact that the call is mostly static (since different input data may generate different call targets). Thus you must do runtime profiling and JITing. Granted, LLVM currently doesn't really do much of this, but the infastructure is there to do so. Andrew

I guess this is slightly offtopic, but the post about the JIT and garbage collection made me wonder why LLVM supports JIT compilation at all. It has much smaller scope for optimisation due to the speed requirements, takes more memory and causes the same work to be repeated over and over for each execution. What reason is there for anything to use JIT compilation over ahead-of-time compiling to

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

...now >>> that it's clearer to me. >> >> Indeed, red/green trees (or DAGs) are one one of the ideas to improve >> loop optimizations, but does justify its use by itself. They happen to >> be effectively necessary for others in the list (e.g. versioning, >> profitiability heuristic by cost function, etc...) and the reason why >> I think the same cannot be done with MLIR. In hindsight, I could have >> pointed this out more in the original RFC. Note that a hierarchical >> representation was not an explicit feature in the list. >> >&gt...