Object: Simplify the IRObjectFile symbol iterator implementation.

Change the IRObjectFile symbol iterator to be a pointer into a vector of
PointerUnions representing either IR symbols or asm symbols

Object: Simplify the IRObjectFile symbol iterator implementation.

Change the IRObjectFile symbol iterator to be a pointer into a vector of
PointerUnions representing either IR symbols or asm symbols.

This change is in preparation for a future change for supporting multiple
modules in an IRObjectFile. Although it causes an increase in memory
consumption, we can deal with that issue separately by introducing a bitcode
symbol table.

Differential Revision: https://reviews.llvm.org/D26928

llvm-svn: 287845

show more ...

Object: Make SymbolicFile::symbol_{begin,end}() virtual and remove unnecessary wrappers.

llvm-svn: 287611

Object: Simplify; remove unnecessary use of unique_ptr.

llvm-svn: 287305

Restore "[ThinLTO] Prevent exporting of locals used/defined in module level asm"

This restores the rest of r286297 (part was restored in r286475).
Specifically, it restores the part requiring adding

Restore "[ThinLTO] Prevent exporting of locals used/defined in module level asm"

This restores the rest of r286297 (part was restored in r286475).
Specifically, it restores the part requiring adding a dependency from
the Analysis to Object library (downstream use changed to correctly
model split BitReader vs BitWriter libraries).

Original description of this part of patch follows:

Module level asm may also contain defs of values. We need to prevent
export of any refs to local values defined in module level asm (e.g. a
ref in normal IR), since that also requires renaming/promotion of the
local. To do that, the summary index builder looks at all values in the
module level asm string that are not marked Weak or Global, which is
exactly the set of locals that are defined. A summary is created for
each of these local defs and flagged as NoRename.

This required adding handling to the BitcodeWriter to look at GV
declarations to see if they have a summary (rather than skipping them
all).

Finally, added an assert to IRObjectFile::CollectAsmUndefinedRefs to
ensure that an MCAsmParser is available, otherwise the module asm parse
would silently fail. Initialized the asm parser in the opt tool for use
in testing this fix.

Fixes PR30610.

llvm-svn: 286844

show more ...

Bitcode: Change module reader functions to return an llvm::Expected.

Differential Revision: https://reviews.llvm.org/D26562

llvm-svn: 286752

Split Bitcode/ReaderWriter.h into separate reader and writer headers

Summary:
Split ReaderWriter.h which contains the APIs into both the BitReader and
BitWriter libraries into BitcodeReader.h and Bi

Split Bitcode/ReaderWriter.h into separate reader and writer headers

Summary:
Split ReaderWriter.h which contains the APIs into both the BitReader and
BitWriter libraries into BitcodeReader.h and BitcodeWriter.h.

This is to address Chandler's concern about sharing the same API header
between multiple libraries (BitReader and BitWriter). That concern is
why we create a single bitcode library in our downstream build of clang,
which led to r286297 being reverted as it added a dependency that
created a cycle only when there is a single bitcode library (not two as
in upstream).

Reviewers: mehdi_amini

Subscribers: dlj, mehdi_amini, llvm-commits

Differential Revision: https://reviews.llvm.org/D26502

llvm-svn: 286566

show more ...

Revert "[ThinLTO] Prevent exporting of locals used/defined in module level asm"

This reverts commit r286297.
Introduces a dependency from libAnalysis to libObject, which I missed
during the review.

Revert "[ThinLTO] Prevent exporting of locals used/defined in module level asm"

This reverts commit r286297.
Introduces a dependency from libAnalysis to libObject, which I missed
during the review.

llvm-svn: 286329

show more ...

[ThinLTO] Prevent exporting of locals used/defined in module level asm

Summary:
This patch uses the same approach added for inline asm in r285513 to
similarly prevent promotion/renaming of locals us

[ThinLTO] Prevent exporting of locals used/defined in module level asm

Summary:
This patch uses the same approach added for inline asm in r285513 to
similarly prevent promotion/renaming of locals used or defined in module
level asm.

All static global values defined in normal IR and used in module level asm
should be included on either the llvm.used or llvm.compiler.used global.
The former were already being flagged as NoRename in the summary, and
I've simply added llvm.compiler.used values to this handling.

Module level asm may also contain defs of values. We need to prevent
export of any refs to local values defined in module level asm (e.g. a
ref in normal IR), since that also requires renaming/promotion of the
local. To do that, the summary index builder looks at all values in the
module level asm string that are not marked Weak or Global, which is
exactly the set of locals that are defined. A summary is created for
each of these local defs and flagged as NoRename.

This required adding handling to the BitcodeWriter to look at GV
declarations to see if they have a summary (rather than skipping them
all).

Finally, added an assert to IRObjectFile::CollectAsmUndefinedRefs to
ensure that an MCAsmParser is available, otherwise the module asm parse
would silently fail. Initialized the asm parser in the opt tool for use
in testing this fix.

Fixes PR30610.

Reviewers: mehdi_amini

Subscribers: johanengelen, krasin, llvm-commits

Differential Revision: https://reviews.llvm.org/D26146

llvm-svn: 286297

show more ...

IR, Bitcode: Change bitcode reader to no longer own its memory buffer.

Unique ownership is just one possible ownership pattern for the memory buffer
underlying the bitcode reader. In practice, as th

IR, Bitcode: Change bitcode reader to no longer own its memory buffer.

Unique ownership is just one possible ownership pattern for the memory buffer
underlying the bitcode reader. In practice, as this patch shows, ownership can
often reside at a higher level. With the upcoming change to allow multiple
modules in a single bitcode file, it will no longer be appropriate for
modules to generally have unique ownership of their memory buffer.

The C API exposes the ownership relation via the LLVMGetBitcodeModuleInContext
and LLVMGetBitcodeModuleInContext2 functions, so we still need some way for
the module to own the memory buffer. This patch does so by adding an owned
memory buffer field to Module, and using it in a few other places where it
is convenient.

Differential Revision: https://reviews.llvm.org/D26384

llvm-svn: 286214

show more ...

[IRObjectFile] Turn llvm_unreachable("foo") into something more explicative.

llvm-svn: 281742

[IRObjectFile] Handle undefined weak symbols in RecordStreamer.

Differential Revision: https://reviews.llvm.org/D24594

llvm-svn: 281629

Restore "Resolution-based LTO API."

This restores commit r278330, with fixes for a few bot failures:
- Fix a late change I had made to the save temps output file that I
missed due to existing file

Restore "Resolution-based LTO API."

This restores commit r278330, with fixes for a few bot failures:
- Fix a late change I had made to the save temps output file that I
missed due to existing files sitting on my disk
- Fix a bunch of Windows bot failures with "ambiguous call to overloaded
function" due to confusion between llvm::make_unique vs
std::make_unique (preface the new make_unique calls with "llvm::")
- Attempt to fix a modules bot failure by adding a missing include
to LTO/Config.h.

Original change:

Resolution-based LTO API.

Summary:
This introduces a resolution-based LTO API. The main advantage of this API over
existing APIs is that it allows the linker to supply a resolution for each
symbol in each object, rather than the combined object as a whole. This will
become increasingly important for use cases such as ThinLTO which require us
to process symbol resolutions in a more complicated way than just adjusting
linkage.

Patch by Peter Collingbourne.

Reviewers: rafael, tejohnson, mehdi_amini

Subscribers: lhames, tejohnson, mehdi_amini, llvm-commits

Differential Revision: https://reviews.llvm.org/D20268

llvm-svn: 278338

show more ...

Revert "Resolution-based LTO API."

This reverts commit r278330.

I made a change to the save temps output that is causing issues with the
bots. Didn't realize this because I had older output files s

Revert "Resolution-based LTO API."

This reverts commit r278330.

I made a change to the save temps output that is causing issues with the
bots. Didn't realize this because I had older output files sitting on
disk in my test output directory.

llvm-svn: 278331

show more ...

Resolution-based LTO API.

Summary:
This introduces a resolution-based LTO API. The main advantage of this API over
existing APIs is that it allows the linker to supply a resolution for each
symbol i

Resolution-based LTO API.

Summary:
This introduces a resolution-based LTO API. The main advantage of this API over
existing APIs is that it allows the linker to supply a resolution for each
symbol in each object, rather than the combined object as a whole. This will
become increasingly important for use cases such as ThinLTO which require us
to process symbol resolutions in a more complicated way than just adjusting
linkage.

Patch by Peter Collingbourne.

Reviewers: rafael, tejohnson, mehdi_amini

Subscribers: lhames, tejohnson, mehdi_amini, llvm-commits

Differential Revision: https://reviews.llvm.org/D20268

Address review comments

llvm-svn: 278330

show more ...

function_refify. NFC.

While there use emplace_back to create an expensive pair.

llvm-svn: 274344

[IRObjectFile] Try to be defensive, add a break.

Suggested by Sean Silva.

llvm-svn: 273519

[IRObjectFile] Propagate .weak attribute correctly for ASM symbols.

PR: 28256
Differential Revision: http://reviews.llvm.org/D21616

llvm-svn: 273474

Don't pass a Reloc::Model to MC.

MC only needs to know if the output is PIC or not. It never has to
decide about creating GOTs and PLTs for example. The only thing that
MC itself uses this informati

Don't pass a Reloc::Model to MC.

MC only needs to know if the output is PIC or not. It never has to
decide about creating GOTs and PLTs for example. The only thing that
MC itself uses this information for is expanding "macros" in sparc and
mips. The rest I am pretty sure could be moved to CodeGen.

This is a cleanup and isolates the code from future changes to
Reloc::Model.

llvm-svn: 269909

show more ...

Return a StringRef from getSection.

This is similar to how getName is handled.

llvm-svn: 269218

Clean the API for CollectAsmUndefinedRefs, taking a Triple and a String InlineAsm instead of a Module (NFC)

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 267106

IRObjectFile, clang-format fixup for r267104

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 267105

Use std::move on the enum to insert it into the pair to please MSVC

(I have no idea why is it needed)
Fixup for r267103

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 267104

Refactor IRObjectFile, extract a static CollectAsmUndefinedRefs() method to parse inline assembly (NFC)

I plan to call this from ThinLTOCodeGenerator.

From: Mehdi Amini <mehdi.amini@apple.com>
llvm

Refactor IRObjectFile, extract a static CollectAsmUndefinedRefs() method to parse inline assembly (NFC)

I plan to call this from ThinLTOCodeGenerator.

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 267103

show more ...

Thread Expected<...> up from createMachOObjectFile() to allow llvm-objdump to produce a real error message

Produce the first specific error message for a malformed Mach-O file describing
the problem

Thread Expected<...> up from createMachOObjectFile() to allow llvm-objdump to produce a real error message

Produce the first specific error message for a malformed Mach-O file describing
the problem instead of the generic message for object_error::parse_failed of
"Invalid data was encountered while parsing the file”.  Many more good error
messages will follow after this first one.

This is built on Lang Hames’ great work of adding the ’Error' class for
structured error handling and threading Error through MachOObjectFile
construction. And making createMachOObjectFile return Expected<...> .

So to to get the error to the llvm-obdump tool, I changed the stack of
these methods to also return Expected<...> :

object::ObjectFile::createObjectFile()
object::SymbolicFile::createSymbolicFile()
object::createBinary()

Then finally in ParseInputMachO() in MachODump.cpp the error can
be reported and the specific error message can be printed in llvm-objdump
and can be seen in the existing test case for the existing malformed binary
but with the updated error message.

Converting these interfaces to Expected<> from ErrorOr<> does involve
touching a number of places. To contain the changes for now use of
errorToErrorCode() and errorOrToExpected() are used where the callers
are yet to be converted.

Also there some were bugs in the existing code that did not deal with the
old ErrorOr<> return values. So now with Expected<> since they must be
checked and the error handled, I added a TODO and a comment:
“// TODO: Actually report errors helpfully” and a call something like
consumeError(ObjOrErr.takeError()) so the buggy code will not crash
since needed to deal with the Error.

Note there is one fix also needed to lld/COFF/InputFiles.cpp that goes along
with this that I will commit right after this. So expect lld not to built
after this commit and before the next one.

llvm-svn: 265606

show more ...

Rename embedded bitcode section in MachO

Summary:
Rename the section embeds bitcode from ".llvmbc,.llvmbc" to "__LLVM,__bitcode".
The new name matches MachO section naming convention.

Reviewers: ra

Rename embedded bitcode section in MachO

Summary:
Rename the section embeds bitcode from ".llvmbc,.llvmbc" to "__LLVM,__bitcode".
The new name matches MachO section naming convention.

Reviewers: rafael, pcc

Subscribers: davide, llvm-commits, joker.eph

Differential Revision: http://reviews.llvm.org/D17388

llvm-svn: 262245

show more ...