[llvm-dev] musttail & alwaysinline interaction

Siddharth Bhat via llvm-dev llvm-dev at lists.llvm.org
Sat Jun 24 08:21:54 PDT 2017


Consider this program:

@globalSideEffect = global i32 0

define void @tobeinlined() #0 {
entry:
  store i32 3, i32* @globalSideEffect, align 4
  musttail call fastcc void @tailcallee(i32 3)
  ret void
}

define fastcc void @tailcallee(i32 %i) {
entry:
    call void @tobeinlined()
    ret void

}

attributes #0 = { alwaysinline }

Clearly, if this is processed with opt -alwaysinline, it will lead to a
correct tail call since the call to "tobeinlined" will be inlined.

However, because opt checks for the correctness of the module when it is
being loaded, it fails the verifyModule() check with:


cannot guarantee tail call due to mismatched parameter counts
  musttail call fastcc void @tailcallee(i32 3)
opt: prelude.inlined.ll: error: input module is broken!

These are just experiment, but I suspect that I will have the same problem
when I am constructing IR with the LLVM API: That is, the verifyModule
sanity check will cause the IR to be considered illegal, *even though the
final IR that would have been generated will be correct.*

What is the correct solution to this when I'm programatically generating IR?

I was considering:

1. generate calls with tail, not musttail
2. Apply AlwaysInline pass to Module
3. Walk module and replace tail with musttail
4. Apply VerifyModule to sanity check

However, that seems like somewhat of a hack. Is there a nicer solution?
Will what I'm trying "just work"?

Thanks,
~Siddharth

-- 
Sending this from my phone, please excuse any typos!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170624/4e72f235/attachment.html>


More information about the llvm-dev mailing list