On Wednesday 25 March 2009, Luke Dalessandro wrote:> You could encode this information as simple library function calls and > then find them again in the generated LLVM IR. The client then just > needs a header declaring the functions and information on what they > mean. Since there are never any definitions of them they won't end up > going anywhere.I've been using this approach now for almost two years in a project and it _seems_ to work fine. However, I'd like to get some feedback from the experts on which kinds of code could be moved by the standard passes over the points in code marked by such calls. For me, loads, stores, and calls to other functions are most interesting. Do the current optimization passes do that? (For example, by checking whether a global's address would escape to external entities like the dummy function that is the marker and allowing accesses to the global to be moved if it doesn't escape.) Thanks, Torvald
On Apr 1, 2009, at 7:25 AM, Torvald Riegel wrote:> On Wednesday 25 March 2009, Luke Dalessandro wrote: >> You could encode this information as simple library function calls >> and >> then find them again in the generated LLVM IR. The client then just >> needs a header declaring the functions and information on what they >> mean. Since there are never any definitions of them they won't end up >> going anywhere. > > I've been using this approach now for almost two years in a project > and it > _seems_ to work fine. However, I'd like to get some feedback from > the experts > on which kinds of code could be moved by the standard passes over > the points > in code marked by such calls. > For me, loads, stores, and calls to other functions are most > interesting. Do > the current optimization passes do that? (For example, by checking > whether a > global's address would escape to external entities like the dummy > function > that is the marker and allowing accesses to the global to be moved > if it > doesn't escape.)Yes, there are current optimizations which do things like this. Global variables are implicitly escaping, because they can be referenced by name, but in other cases LLVM does determine variables that don't escape and performs optimizations accordingly. Dan
On Wednesday 01 April 2009 20:01:09 Dan Gohman wrote:> On Apr 1, 2009, at 7:25 AM, Torvald Riegel wrote: > > On Wednesday 25 March 2009, Luke Dalessandro wrote: > >> You could encode this information as simple library function calls > >> and > >> then find them again in the generated LLVM IR. The client thenjust> >> needs a header declaring the functions and information on whatthey> >> mean. Since there are never any definitions of them they won'tend up> >> going anywhere. > > > > I've been using this approach now for almost two years in a project > > and it > > _seems_ to work fine. However, I'd like to get some feedback from > > the experts > > on which kinds of code could be moved by the standard passes over > > the points > > in code marked by such calls. > > For me, loads, stores, and calls to other functions are most > > interesting. Do > > the current optimization passes do that? (For example, by checking > > whether a > > global's address would escape to external entities like the dummy > > function > > that is the marker and allowing accesses to the global to be moved > > if it > > doesn't escape.) > > Yes, there are current optimizations which do things like this. Global > variables are implicitly escaping, because they can be referenced by > name, but in other cases LLVM does determine variables that don't > escape and performs optimizations accordingly.Can you tell me more about "the other cases", or categorize them in some way? For example, does this apply to thread-local variables only (which would be okay in my case), or do LLVM passes also check whether arbitrary pointers (eg, passed in via function arguments) escape? Thanks, Torvald