[LLVMdev] pragmas

[Anthony Danalis]

On Apr 6, 2009, at 3:38 PM, Torvald Riegel wrote:

> 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 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.
>
> 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?

If the functions will never really execute because your optimization  
pass is
going to remove them, I would expect that setting  
"setDoesNotAccessMemory"
on the callsites could help other optimizations.

Anthony