search for: d10059

Hi Sundeep, I am also interested in the load-store lifting transformation. For static globals as-in your example, the transformation in general would rely on a better static global aliasing information that is currently in review http://reviews.llvm.org/D10059 For non-static globals, one problem with loop-based analysis alone is that in a popular embedded benchmark suite, you get serious gains if you can localize the globals in code like int *G1; int *G2; foo () { G1 = malloc(...); for (...) { // Lots of stuff with G1 and G2 worth localizin...

...ven locally) without notifying the AA infrastructure. I can't think of any in-tree pass that does this now, although we might certainly have some in the future. Can you think of any we have now? I'd really like to get the AA pass that Sam Parker has been working on (http://reviews.llvm.org/D10059) in, but it will add measurable compile-time overhead if it can't cache, and efficient caching seems to depend on the same property. -Hal > Are you aware of any miscompiles that might be attributed > to this, or are these “theoretical" concerns? > > -Chris > > --...

Hello all, I am writing to get some feedback on an optimization that I would like to upstream. The basic idea is to localize global variables inside loops so that it can be allocated into registers. For example, transform the following sequence static int gbl_var; void foo() { for () { ...access gbl_var... } } into something like static int gbl_var; void foo() { int lcl_var;

Ok folks, I wrote up the general high-level thoughts I have about stateful AA in a separate thread. But we need to sort out the completely and horribly broken aspects of GlobalsModRef today, and the practical steps forward. This email is totally about the practical stuff. Now, as to why I emailed this group of people and with this subject, the only pass pipeline that includes GlobalsModRef, is