search for: unspecialized

...39;m facing a performance hurdle. I'm currently performing the specialization during the AST to LLVM IR translation, but unfortunately this leads to relatively slow recompiles as LLVM has to perform all the heavy (optimization) passes over and over again. So I was hoping that by first creating unspecialized LLVM IR, optimizing that as much as possible, and then performing the specializations starting from this optimized IR, the recompiles would be significantly faster. Currently the mem2reg and instcombine passes take the majority of compilation time, which could be avoided using "deep" JIT...

Hi Chris, Thanks for pointing me to that presentation! It helped me come up with a strategy that I believe might work: 1) Use CloneFunction() to make a copy of the original unspecialized (but optimized) function. 2) Specialize it using a custom function pass which identifies the specialization parameters and substitutes them with given run-time constants. 3) Run the function through a FunctionPassManager with some post-specialization optimization passes (dead code, etc). 4) Use get...

...a performance hurdle. I'm currently performing the specialization during the AST to LLVM IR translation, but unfortunately this leads to relatively slow recompiles as LLVM has to perform all the heavy (optimization) passes over and over again. > > So I was hoping that by first creating unspecialized LLVM IR, optimizing that as much as possible, and then performing the specializations starting from this optimized IR, the recompiles would be significantly faster. Currently the mem2reg and instcombine passes take the majority of compilation time, which could be avoided using "deep" JIT...

...e hurdle. I'm currently performing the specialization during the > AST to LLVM IR translation, but unfortunately this leads to relatively slow > recompiles as LLVM has to perform all the heavy (optimization) passes over > and over again. > > So I was hoping that by first creating unspecialized LLVM IR, optimizing > that as much as possible, and then performing the specializations starting > from this optimized IR, the recompiles would be significantly faster. > Currently the mem2reg and instcombine passes take the majority of > compilation time, which could be avoided using &...

...not obvious to me from glancing at the code. FWIW, I'm hoping it can be cleaned up gradually, maybe for the next release. The preRA scheduler is bottom-up, for register pressure tracking. The postRA scheduler is top-down, for simpler hazard detection logic. On ARM, the preRA scheduler uses an unspecialized instance of ScoreboardHazardRecognizer. The machine-independent RecedeCycle() logic that operates on the scheduler itinerary is sufficient. The ARM postRA scheduler specializes the HazardRecognizer to handle additional constraints that cannot be expressed in the itinerary. Since this is a top-down...

Andy, I should have been more clear, the ARM implementation has: void ARMHazardRecognizer::RecedeCycle() { llvm_unreachable("reverse ARM hazard checking unsupported"); } How does that work? Thanks again, Hal On Tue, 2011-11-29 at 09:47 -0800, Andrew Trick wrote: > ARM can reuse all the default scoreboard hazard recognizer logic such as recede cycle (naturally since its the

On Apr 16, 2008, at 2:50 AM, heisenbug wrote: > > And now here is my educated speculation: > There are 2 things that became slower > 1) Use::getUser() > 2) Use::get/set due to tagging. > > The former is seldom called: > > $ find lib -name "*.cpp" | xargs grep "getUser(" | wc -l > 41 The majority of those aren't actually Use::getUser, but

ARM can reuse all the default scoreboard hazard recognizer logic such as recede cycle (naturally since its the primary client). If you can do the same with PPC that's great. Andy On Nov 29, 2011, at 8:51 AM, Hal Finkel <hfinkel at anl.gov> wrote: >> Thanks! Since I have to change PPCHazardRecognizer for bottom-up support >> anyway, is there any reason not to have it

On Apr 16, 2:13 am, Dan Gohman <goh... at apple.com> wrote: > Hi Gabor, > > Can you provide performance data for this? I'd > like to know what affect these changes have on > compile time. Hi Dan, Unfortunately, no. I can feed you with some speculation, though, see below. The reason why I cannot do measurements (at the moment) is that - I have no experience with