Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PR for llvm/llvm-project#52787 #167

Open
wants to merge 1 commit into
base: release/14.x
Choose a base branch
from
Open

PR for llvm/llvm-project#52787 #167

wants to merge 1 commit into from

Commits on Apr 12, 2022

  1. [Bitcode] materialize Functions early when BlockAddress taken

    IRLinker builds a work list of functions to materialize, then moves them
    from a source module to a destination module one at a time.
    
    This is a problem for blockaddress Constants, since they need not refer
    to the function they are used in; IPSCCP is quite good at sinking these
    constants deep into other functions when passed as arguments.
    
    This would lead to curious errors during LTO:
      ld.lld: error: Never resolved function from blockaddress ...
    based on the ordering of function definitions in IR.
    
    The problem was that IRLinker would basically do:
    
      for function f in worklist:
        materialize f
        splice f from source module to destination module
    
    in one pass, with Functions being lazily added to the running worklist.
    This confuses BitcodeReader, which cannot disambiguate whether a
    blockaddress is referring to a function which has not yet been parsed
    ("materialized") or is simply empty because its body was spliced out.
    This causes BitcodeReader to insert Functions into its BasicBlockFwdRefs
    list incorrectly, as it will never re-materialize an already
    materialized (but spliced out) function.
    
    Because of the possibility that blockaddress Constants may appear in
    Functions other than the ones they reference, this patch adds a new
    bitcode function code FUNC_CODE_BLOCKADDR_USERS that is a simple list of
    Functions that contain BlockAddress Constants that refer back to this
    Function, rather then the Function they are scoped in. We then
    materialize those functions when materializing `f` from the example loop
    above. This might over-materialize Functions should the user of
    BitcodeReader ultimately decide not to link those Functions, but we can
    at least now we can avoid this ordering related issue with blockaddresses.
    
    Fixes: llvm#52787
    Fixes: ClangBuiltLinux/linux#1215
    
    Reviewed By: dexonsmith
    
    Differential Revision: https://reviews.llvm.org/D120781
    
    (cherry picked from commit 23ec578)
    nickdesaulniers authored and llvmbot committed Apr 12, 2022
    Configuration menu
    Copy the full SHA
    1a7daf8 View commit details
    Browse the repository at this point in the history