> only if the compiler can prove that the called function has > no side effects (such as modifying some global variables or > causing the program to exit).can it prove if the function resides in a shared library? -- View this message in context: http://old.nabble.com/DCE-and-external-function-tp29932485p29942236.html Sent from the LLVM - Dev mailing list archive at Nabble.com.
>> only if the compiler can prove that the called function has >> no side effects (such as modifying some global variables or >> causing the program to exit). > > can it prove if the function resides in a shared library?No, however it can prove it if the function is in a static library consisting of bitcode files (what you get if you compile with -emit-llvm) and you do link-time optimization. However it's probably simpler to declare the function as having no side-effects using gcc's "pure" or "const" attribute. Ciao, Duncan.
On Tue, Oct 12, 2010 at 1:21 PM, leledumbo <leledumbo_cool at yahoo.co.id> wrote:> >> only if the compiler can prove that the called function has >> no side effects (such as modifying some global variables or >> causing the program to exit). > > can it prove if the function resides in a shared library?Only if the right function attributes are added. See http://llvm.org/docs/LangRef.html#fnattrs for a list, but 'readonly'/'readnone' and 'nounwind' will be most interesting for you here. I guess calling abort() probably disqualifies a function for 'readonly' (and it's stronger variant 'readnone'). Currently calls to any function that has either of the readnone or readonly attributes as well as the nounwind attribute qualify as "trivially dead" if their results aren't used, meaning lots of optimizations will get rid of them. (in particular, this is pretty much the entire the job of -die and -dce, but many others will delete them rather than change or move them if they get in the way) As Duncan said while I was typing this, putting __attribute__((pure)) or __attribute__((const)) on the declaration will add those llvm attributes if you're using llvm-gcc or clang to generate this llvm assembly. Note that there doesn't seem to be a function attribute to say "this function won't go into an infinite loop" though, which I guess means http://llvm.org/PR965 hasn't been fixed yet.
> No, however it can prove it if the function is in a static libraryconsisting> of bitcode files (what you get if you compile with -emit-llvm) and you do > link-time optimization. However it's probably simpler to declare the > function > as having no side-effects using gcc's "pure" or "const" attribute.Hmm... the library can't be made static so I guess it's OK.> Only if the right function attributes are added. See > http://llvm.org/docs/LangRef.html#fnattrs for a list, but > 'readonly'/'readnone' and 'nounwind' will be most interesting for you > here. I guess calling abort() probably disqualifies a function for > 'readonly' (and it's stronger variant 'readnone'). > Currently calls to any function that has either of the readnone or > readonly attributes as well as the nounwind attribute qualify as > "trivially dead" if their results aren't used, meaning lots of > optimizations will get rid of them. (in particular, this is pretty > much the entire the job of -die and -dce, but many others will delete > them rather than change or move them if they get in the way)Without those attributes, will the optimizer assume something? Actually, I don't use llvm-gcc here. I'm creating a compiler for a language defined by my professor that generates llvm assembly language, for my bachelor graduation project. The language is database centric but isn't tight to any database implementation. For my implementation, it's decided to use postgresql, and to concentrate more in the language rather than the database I create a shared library for most commonly database related functionality (connect, disconnect, getting error message, query) so I can just declare and call it from the generated llvm assembly. What I'm afraid of is, for example, return value of a call to connect function may be ignored, and the optimizer will eliminate the call due to this. -- View this message in context: http://old.nabble.com/DCE-and-external-function-tp29932485p29949646.html Sent from the LLVM - Dev mailing list archive at Nabble.com.