llvm dev - Jan 2013 - [LLVMdev] FunctionPass question

Hi,

I am working on a pass to convert lib calls to intrinsic calls as discussed
here: http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-January/058507.html

In my first attempt I created a FunctionPass that uses
CallInst::setCalledFunction to replace the callee with the appropriate intrinsic
(using Intrinsic::getDeclaration).

After the pass runs I get an assertion from CallGraphSCCPass:

clang-3.3:
/home/predmond/src/ssg_llvm/llvm/lib/Analysis/IPA/CallGraphSCCPass.cpp:338: bool
{anonymous}::CGPassManager::RefreshCallGraph(llvm::CallGraphSCC&,
llvm::CallGraph&, bool): Assertion `CallSites.empty() &&
"Dangling pointers found in call sites map"' failed.

My guess is that I'm modifying the module illegally in a FunctionPass and
things break. I see a similar approach used in InstCombineCall however the
difference is setCalledFunction is used to replace one intrinsic with another.

The obvious fix (which works) is to use a ModulePass but I'm wondering if
there's a way to make this work with a FunctionPass.

paul

Hi Paul,
> I am working on a pass to convert lib calls to intrinsic calls as discussed
here: http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-January/058507.html
this whole area is a little confusing.  If you can recognize a libcall as
being equivalent to an intrinsic, you could indeed turn it into an intrinsic,
but on the other hand you could just directly do on it the IR transforms you
want to do on the builtin.  At the IR level turning it into an intrinsic
doesn't
buy you much.  If it's not buying you anything, why do it?  On the other
hand,
you might then wonder why the intrinsics exist at all.  One answer is that you
can use the intrinsics with vectors, which isn't usually the case with the
libcall versions.

At the codegen level things are a bit different.  If a libcall can be correctly
turned into a target processor instruction, then at some point that conversion
has to happen.  Thus the recognition of certain libcalls, and their conversion
into a SDNode.

Ciao, Duncan.
>
> In my first attempt I created a FunctionPass that uses
CallInst::setCalledFunction to replace the callee with the appropriate intrinsic
(using Intrinsic::getDeclaration).
>
> After the pass runs I get an assertion from CallGraphSCCPass:
>
> clang-3.3:
/home/predmond/src/ssg_llvm/llvm/lib/Analysis/IPA/CallGraphSCCPass.cpp:338: bool
{anonymous}::CGPassManager::RefreshCallGraph(llvm::CallGraphSCC&,
llvm::CallGraph&, bool): Assertion `CallSites.empty() &&
"Dangling pointers found in call sites map"' failed.
>
> My guess is that I'm modifying the module illegally in a FunctionPass
and things break. I see a similar approach used in InstCombineCall however the
difference is setCalledFunction is used to replace one intrinsic with another.
>
> The obvious fix (which works) is to use a ModulePass but I'm wondering
if there's a way to make this work with a FunctionPass.
>
> paul
>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

Hi Duncan,

On 2013-01-24, at 4:23 PM, Duncan Sands wrote:
> Hi Paul,
> 
>> I am working on a pass to convert lib calls to intrinsic calls as
discussed here:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-January/058507.html
> 
> this whole area is a little confusing.  If you can recognize a libcall as
> being equivalent to an intrinsic, you could indeed turn it into an
intrinsic,
> but on the other hand you could just directly do on it the IR transforms
you
> want to do on the builtin.  At the IR level turning it into an intrinsic
doesn't
> buy you much.  If it's not buying you anything, why do it?  On the
other hand,
> you might then wonder why the intrinsics exist at all.  One answer is that
you
> can use the intrinsics with vectors, which isn't usually the case with
the
> libcall versions.
> 
The nice thing about the intrinsic forms is that you don't need to consider
multiple types.

For example the loop vectorizer can vectorize sin intrinsics for any float type.
To support sinf, sin, sinl you would have to have a case for each.

Another example can be found in the list of TODOs at the bottom of
SimplifyLibCalls.cpp. Most of those transformation could be implemented with
InstCombine rules to handle all types if given intrinsics.

I'm certainly open to any feedback or suggestions. 

paul
> At the codegen level things are a bit different.  If a libcall can be
correctly
> turned into a target processor instruction, then at some point that
conversion
> has to happen.  Thus the recognition of certain libcalls, and their
conversion
> into a SDNode.
> 
> Ciao, Duncan.