[LLVMdev] DCE and external function

leledumbo leledumbo_cool at yahoo.co.id
Tue Oct 12 22:14:57 PDT 2010


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

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.




More information about the llvm-dev mailing list