Summary:
llc would hit a fatal error for errors in inline assembly. The
diagnostics message is now printed.
Reviewers: rengolin, MatzeB, javed.absar, anemet
Reviewed By: anemet
Subscribers: jyknight, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D29408
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@293999 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This is necessary to get stats from the ThinLink printed before the
early exit when compiling in a distributed build.
Reviewers: mehdi_amini
Subscribers: Prazek, llvm-commits
Differential Revision: https://reviews.llvm.org/D29461
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@293908 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
dsymutil upgrade path can change the size of segment and it needs to update
the vmsize of the segment to reflect the size change.
rdar://problem/30290714
Reviewers: friss
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29433
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@293842 91177308-0d34-0410-b5e6-96231b3b80d8
This introduces the `analyze` subcommand. For now there is only
one option, to analyze hash collisions in the type streams. In
the future, however, we could add many more things here, such
as performing size analyses, compacting, and statistics about
the type of records etc.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@293795 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This change implements the instrumentation map loading library which can
understand both YAML-defined instrumentation maps, and ELF 64-bit object
files that have the XRay instrumentation map section. We break it out
into a library on its own to allow for other applications to deal with
the XRay instrumentation map defined in XRay-instrumented binaries.
This type provides both raw access to the logical representation of the
instrumentation map entries as well as higher level functions for
converting a function ID into a function address.
At this point we only support ELF64 binaries and YAML-defined XRay
instrumentation maps. Future changes should extend this to support
32-bit ELF binaries, as well as other binary formats (like MachO).
As part of this change we also migrate all uses of the extraction logic
that used to be defined in tools/llvm-xray/ to use this new type and
interface for loading from files. We also remove the flag from the
`llvm-xray` tool that required users to specify the type of the
instrumentation map file being provided to instead make the library
auto-detect the file type.
Reviewers: dblaikie
Subscribers: mgorny, varno, llvm-commits
Differential Revision: https://reviews.llvm.org/D29319
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@293721 91177308-0d34-0410-b5e6-96231b3b80d8
without symbols that makes calls through a symbol stub which were not
correctly being annotated with “## symbol stub for: _foo”.
Just adds the same parameters for getting the annotations from
DisAsm->getInstruction() and passing them to IP->printInst() from the
code above when boolean variable symbolTableWorked was true.
rdar://29791952
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@293662 91177308-0d34-0410-b5e6-96231b3b80d8
Clang complains about an ambiguous call to printNumber() because it
can't work out what size_t should convert to. I picked uint64_t.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@293573 91177308-0d34-0410-b5e6-96231b3b80d8
To better match the old darwin otool(1) behavior, when llvm-obdump(1) is used
with the -macho option and the input file is not an object file simply print
the file name and this message:
foo: is not an object file
and continue on to process other input files. Also in this case don’t exit
non-zero. This should help in some OSS projects' with autoconf scripts
that are expecting the old darwin otool(1) behavior.
rdar://26828015
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@293547 91177308-0d34-0410-b5e6-96231b3b80d8
We had various variants of defining dump() functions in LLVM. Normalize
them (this should just consistently implement the things discussed in
http://lists.llvm.org/pipermail/cfe-dev/2014-January/034323.html
For reference:
- Public headers should just declare the dump() method but not use
LLVM_DUMP_METHOD or #if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP)
- The definition of a dump method should look like this:
#if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP)
LLVM_DUMP_METHOD void MyClass::dump() {
// print stuff to dbgs()...
}
#endif
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@293359 91177308-0d34-0410-b5e6-96231b3b80d8
R_X86_64_NONE can be emitted without a symbol associated (well,
in theory it should never be emitted in an ABI-compliant relocatable
object). So, if there's no symbol associated to a reloc, emit one
with an empty name, instead of crashing.
Ack'ed by Michael Spencer offline.
PR: 31768
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@293224 91177308-0d34-0410-b5e6-96231b3b80d8
This change introduces adjustPassManager target callback giving a
target an opportunity to tweak PassManagerBuilder before pass
managers are populated.
This generalizes and replaces addEarlyAsPossiblePasses target
callback. In particular that can be used to add custom passes to
extension points other than EP_EarlyAsPossible.
Differential Revision: https://reviews.llvm.org/D28336
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@293189 91177308-0d34-0410-b5e6-96231b3b80d8
This is the opt/llc counterpart of -fsave-optimization-record to output
optimization remarks in a YAML file.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@293121 91177308-0d34-0410-b5e6-96231b3b80d8
This allows MIR passes to emit optimization remarks with the same level
of functionality that is available to IR passes.
It also hooks up the greedy register allocator to report spills. This
allows for interesting use cases like increasing interleaving on a loop
until spilling of registers is observed.
I still need to experiment whether reporting every spill scales but this
demonstrates for now that the functionality works from llc
using -pass-remarks*=<pass>.
Differential Revision: https://reviews.llvm.org/D29004
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@293110 91177308-0d34-0410-b5e6-96231b3b80d8
Mach-O files don’t have size information about the symbols in the object file
format unlike ELF.
Also add the part of the fix to llvm-nm that was missed with r290001 so
-arch armv7m works.
rdar://25681018
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@293099 91177308-0d34-0410-b5e6-96231b3b80d8
This is not a list of pairs, it is a hash table data structure. We now
correctly parse this out and dump it from llvm-pdbdump.
We still need to understand the conditions that lead to a type
getting an entry in the hash adjuster table. That will be done
in a followup investigation / patch.
Differential Revision: https://reviews.llvm.org/D29090
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@293090 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
A patch to enable the llvm-xray graph subcommand to color edges and
vertices based on statistics and to annotate vertices with statistics.
Depends on D27243
Reviewers: dblaikie, dberris
Reviewed By: dberris
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D28225
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@293031 91177308-0d34-0410-b5e6-96231b3b80d8
in llvm-objdump for Mach-O files add the printing of the
x86_thread_state32_t in the same format as
otool-classic(1) on darwin.
To do this the 32-bit x86 general tread state
needed to be defined in include/llvm/Support/MachO.h .
rdar://30110111
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@292829 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Add a new load command LC_BUILD_VERSION. It is a generic version of
LC_*_VERSION_MIN load_command used on Apple platforms. Instead of having
a seperate load command for each platform, LC_BUILD_VERSION is recording
platform info as an enum. It also records SDK version, min_os, and tools
that used to build the binary.
rdar://problem/29781291
Reviewers: enderby
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29044
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@292824 91177308-0d34-0410-b5e6-96231b3b80d8
Add the `--strip-underscore` option to llvm-cxxfilt to strip the leading
underscore. This is useful for when dealing with targets which add a
leading underscore.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@292759 91177308-0d34-0410-b5e6-96231b3b80d8
This is a stub implementation of the `-s` or `--format` option that
allows the user to specify the demangling style. Since we only support
the Itanium (GNU) style demangling, auto is synonymous with `gnu`.
Simply swallow the option to permit some level of commandline
compatibility.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@292706 91177308-0d34-0410-b5e6-96231b3b80d8
While the builder pattern has proven useful for certain other
larger types, in this case it was hampering the ability to use
the data structure, as for runtime access we need a map that
we can efficiently read from and write to. So the two are merged
into a single data structure that can efficiently be read to,
written from, deserialized from bytes, and serialized to bytes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@292664 91177308-0d34-0410-b5e6-96231b3b80d8
Fix a silly copy-paste error in the tool description. Take the
opportunity to add crash stack printing which will hopefully never be
needed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@292579 91177308-0d34-0410-b5e6-96231b3b80d8
By default c++filt demangles functions, though you can optionally pass
`-t` to have it decode types as well, behaving nearly identical to
`__cxa_demangle`. Add support for this mode.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@292576 91177308-0d34-0410-b5e6-96231b3b80d8
It describes a region of arbitrary data included in a Mach-O file.
Its initial use is to record extra data in MH_CORE files.
rdar://30001545
rdar://30001731
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@292500 91177308-0d34-0410-b5e6-96231b3b80d8
c++filt does not attempt to demangle symbols which do not match its
expected format. This means that the symbol must start with _Z or ___Z
(block invocation function extension). Any other symbols are returned
as is. Note that this is different from the behaviour of __cxa_demangle
which will demangle fragments.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@292467 91177308-0d34-0410-b5e6-96231b3b80d8
Enable an ELFObjectFile to read the its arm build attributes to
produce a target triple with a specific ARM architecture.
llvm-objdump now uses this functionality to automatically produce
a more accurate target.
Differential Revision: https://reviews.llvm.org/D28769
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@292366 91177308-0d34-0410-b5e6-96231b3b80d8
Here we define the `graph` subcommand which generates a graph from the function
call information and uses it to present the call information graphically with
additional annotations.
Reviewers: dblaikie, dberris
Differential Revision: https://reviews.llvm.org/D27243
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@292156 91177308-0d34-0410-b5e6-96231b3b80d8
std::to_string is not available in the android ndk. Using llvm::to_string
instead.
Committing as obvious.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@292143 91177308-0d34-0410-b5e6-96231b3b80d8
This is uncovered when running tools/dsymutil/X86/empty_range.s.test
with ASAN. Haven't investigate yet, whether that means there is an ODR
violation in that test.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@292065 91177308-0d34-0410-b5e6-96231b3b80d8
Removed all DWARFDie::getAttributeValueAs*() calls.
Renamed:
Optional<DWARFFormValue> DWARFDie::getAttributeValue(dwarf::Attribute);
To:
Optional<DWARFFormValue> DWARFDie::find(dwarf::Attribute);
Added:
Optional<DWARFFormValue> DWARFDie::findRecursively(dwarf::Attribute);
All decoding of Optional<DWARFFormValue> values are now done using the dwarf::to*() functions from DWARFFormValue.h:
Old code:
auto DeclLine = DWARFDie.getAttributeValueAsSignedConstant(DW_AT_decl_line).getValueOr(0);
New code:
auto DeclLine = toUnsigned(DWARFDie.find(DW_AT_decl_line), 0);
This composition helps us since we can now easily do:
auto DeclLine = toUnsigned(DWARFDie.findRecursively(DW_AT_decl_line), 0);
This allows us to easily find attribute values in the current DIE only (the first new code above) or in any DW_AT_abstract_origin or DW_AT_specification Dies using the line above. Note that the code line length is shorter and more concise.
Differential Revision: https://reviews.llvm.org/D28581
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291959 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Revert [ARM] Fix ubig32_t read in ARMAttributeParser
Now using support functions to read data instead of trying to
perform casts.
===========================================================
Revert [ARM] Enable objdump to construct triple for ARM
Now that The ARMAttributeParser has been moved into the library,
it has been modified so that it can parse the attributes without
printing them and stores them in a map. ELFObjectFile now queries
the attributes to fill out the architecture details of a provided
triple for 'arm' and 'thumb' targets. llvm-objdump uses this new
functionality.
Subscribers: llvm-commits, samparker, aemerson, mgorny
Differential Revision: https://reviews.llvm.org/D28683
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291911 91177308-0d34-0410-b5e6-96231b3b80d8
Now that The ARMAttributeParser has been moved into the library,
it has been modified so that it can parse the attributes without
printing them and stores them in a map. ELFObjectFile now queries
the attributes to fill out the architecture details of a provided
triple for 'arm' and 'thumb' targets. llvm-objdump uses this new
functionality.
Differential Revision: https://reviews.llvm.org/D28281
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291898 91177308-0d34-0410-b5e6-96231b3b80d8
This patch pulls the yaml2dwarf code out of yaml2obj into a new set of DWARF emitter functions in the DWARFYAML namespace. This will enable the YAML->DWARF code to be used inside DWARF tests by populating the DWARFYAML structs and calling the Emitter functions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291828 91177308-0d34-0410-b5e6-96231b3b80d8
The code parsing the string was using the offset returned from
StringRef::find() wrong, assuming it was relative to the staring
offset that is passed to the function, but the returned offset
is always relative to the beginning of the line.
This causes odd behaviour while parsing the component string.
Spotted thanks to the newly added test:
tools/llvm-config/booleans.test
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291803 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This is the third of a multi-part change to implement subcommands for
the `llvm-xray` tool.
Here we define the `account` subcommand which does simple function call
accounting, generating basic statistics on function calls we find in an
XRay log/trace. We support text output and csv output for this
subcommand.
This change also supports sorting, summing, and filtering the top N
results.
Part of this tool will later be turned into a library that could be used
for basic function call accounting.
Depends on D24376.
Reviewers: dblaikie, echristo
Subscribers: mehdi_amini, dberris, beanz, llvm-commits
Differential Revision: https://reviews.llvm.org/D24377
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291749 91177308-0d34-0410-b5e6-96231b3b80d8
Previously the type dumper itself was passed around to a lot of different
places and manipulated in ways that were more appropriate on the type
database. For example, the entire TypeDumper was passed into the symbol
dumper, when all the symbol dumper wanted to do was lookup the name of a
TypeIndex so it could print it. That's what the TypeDatabase is for --
mapping type indices to names.
Another example is how if the user runs llvm-pdbdump with the option to
dump symbols but not types, we still have to visit all types so that we
can print minimal information about the type of a symbol, but just without
dumping full symbol records. The way we did this before is by hacking it
up so that we run everything through the type dumper with a null printer,
so that the output goes to /dev/null. But really, we don't need to dump
anything, all we want to do is build the type database. Since
TypeDatabaseVisitor now exists independently of TypeDumper, we can do
this. We just build a custom visitor callback pipeline that includes a
database visitor but not a dumper.
All the hackery around printers etc goes away. After this patch, we could
probably even delete the entire CVTypeDumper class since really all it is
at this point is a thin wrapper that hides the details of how to build a
useful visitation pipeline. It's not a priority though, so CVTypeDumper
remains for now.
After this patch we will be able to easily plug in a different style of
type dumper by only implementing the proper visitation methods to dump
one-line output and then sticking it on the pipeline.
Differential Revision: https://reviews.llvm.org/D28524
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291724 91177308-0d34-0410-b5e6-96231b3b80d8
the latter to the Transforms library.
While the loop PM uses an analysis to form the IR units, the current
plan is to have the PM itself establish and enforce both loop simplified
form and LCSSA. This would be a layering violation in the analysis
library.
Fundamentally, the idea behind the loop PM is to *transform* loops in
addition to running passes over them, so it really seemed like the most
natural place to sink this was into the transforms library.
We can't just move *everything* because we also have loop analyses that
rely on a subset of the invariants. So this patch splits the the loop
infrastructure into the analysis management that has to be part of the
analysis library, and the transform-aware pass manager.
This also required splitting the loop analyses' printer passes out to
the transforms library, which makes sense to me as running these will
transform the code into LCSSA in theory.
I haven't split the unittest though because testing one component
without the other seems nearly intractable.
Differential Revision: https://reviews.llvm.org/D28452
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291662 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
In this change we move the definition of the log reading routines from
the tools directory in LLVM to {include/llvm,lib}/XRay. We improve the
documentation a little bit for the publicly accessible headers, and
adjust the top-matter. This also leads to some refactoring and cleanup
in the tooling code.
In particular, we do the following:
- Rename the class from LogReader to Trace, as it better represents
the logical set of records as opposed to a log.
- Use file type detection instead of asking the user to say what
format the input file is. This allows us to keep the interface
simple and encapsulate the logic of loading the data appropriately.
In future changes we increase the API surface and write dedicated unit
tests for the XRay library.
Depends on D24376.
Reviewers: dblaikie, echristo
Subscribers: mehdi_amini, mgorny, llvm-commits, varno
Differential Revision: https://reviews.llvm.org/D28345
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291652 91177308-0d34-0410-b5e6-96231b3b80d8
We were starting to get some name clashes between llvm-pdbdump
and the common CodeView framework, so I took this opportunity
to rename a bunch of files to more accurately describe their
usage. This also helps in llvm-pdbdump to distinguish
between different files and whether they are used for pretty
dump mode or raw dump mode.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291627 91177308-0d34-0410-b5e6-96231b3b80d8
Following the similar change to lit configuration, ensure that all CMake
booleans are canonicalized to 0/1 when being passed to llvm-config. This
fixes the incorrect interpretation of values when user passes another
value than the ON/OFF, and simplifies the code by removing unnecessary
string matching.
Furthermore, the code for --has-rtti and --has-global-isel has been
modified to print consistent values indepdently of the boolean used by
passed by the user to CMake. Sadly, the code already implicitly used
different values for the two (YES/NO for --has-rtti, ON/OFF for
--has-global-isel).
Include tests for all booleans and multi-value options in llvm-config.
Differential Revision: https://reviews.llvm.org/D28366
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291593 91177308-0d34-0410-b5e6-96231b3b80d8
One more try... relanding r291541 with a fix to properly gate MaxOpsPerInst on DWARF version.
Description from r291541:
This patch re-lands r291470, which failed on Linux bots. The issue (I believe) was undefined behavior because the size of llvm::dwarf::LineNumberOps was not explcitly specified or consistently respected. The updated patch adds an explcit underlying type to the enum and preserves the size more correctly.
Original description:
This patch adds support for the DWARF debug_lines section. The line table state machine opcodes are preserved, so this can be used to test the state machine evaluation directly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291546 91177308-0d34-0410-b5e6-96231b3b80d8
This patch re-lands r291470, which failed on Linux bots. The issue (I believe) was undefined behavior because the size of llvm::dwarf::LineNumberOps was not explcitly specified or consistently respected. The updated patch adds an explcit underlying type to the enum and preserves the size more correctly.
Original description:
This patch adds support for the DWARF debug_lines section. The line table state machine opcodes are preserved, so this can be used to test the state machine evaluation directly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291541 91177308-0d34-0410-b5e6-96231b3b80d8
This is the second part of a multi-part change to define additional
subcommands to the `llvm-xray` tool.
This change defines a conversion subcommand to take XRay log files, and
turns them from one format to another (binary or YAML). This currently
only supports the first version of the log file format, defined in the
compiler-rt runtime.
Depends on D21987.
Reviewers: dblaikie, echristo
Subscribers: mehdi_amini, dberris, beanz, llvm-commits
Differential Revision: https://reviews.llvm.org/D24376
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291529 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds support for the DWARF debug_lines section. The line table state machine opcodes are preserved, so this can be used to test the state machine evaluation directly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291470 91177308-0d34-0410-b5e6-96231b3b80d8
Running a Debug build of objdump -objc-meta-data with a large Mach-O file is
currently unnecessarily slow.
With some local test input, this change reduces the run time from 75-85s down
to 15-20s.
The two changes are:
Assert on pointer equality not array equality
Replace vector<pair<address, symbol>> with DenseMap<address, symbol>
Additionally, use a std::unique_ptr rather than handling the memory manually.
Patch by Dave Lee!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291398 91177308-0d34-0410-b5e6-96231b3b80d8
Don't print a line multiple times, each for different inlining contexts, if
nothing happened in any context. This prevents situations like this:
[[
> main:
65 | if ((i * ni + j) % 20 == 0) fprintf
> print_array:
65 | if ((i * ni + j) % 20 == 0) fprintf
]]
which could happen if different optimizations were missed in different inlining
contexts.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291361 91177308-0d34-0410-b5e6-96231b3b80d8
Modify the --system-libs option in llvm-config to print system libs only
when using static linking. The system libraries are irrelevant when
linking to a shared library since the library has appropriate library
dependencies embedded.
Modify the --system-libs test appropriately to force static linking, and
disable it if static libs are not available (i.e. BUILD_SHARED_LIBS is
enabled).
Differential Revision: https://reviews.llvm.org/D27805
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291285 91177308-0d34-0410-b5e6-96231b3b80d8
Add a --cmakedir option to llvm-config that returns the correct path to
built/installed CMake modules (i.e. lib/cmake/llvm). This is mostly
intended as a convenience option for stand-alone builds of other LLVM
projects that frequently reconstruct LLVM_CMAKE_PATH after querying
llvm-config.
Differential Revision: https://reviews.llvm.org/D26894
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@291218 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Change llvm-link to use the FunctionImporter handling, instead of
manually invoking the Linker. We still need to load the module
in llvm-link to do the desired testing for invalid import requests
(weak functions), and to get the GUID (in case the function is local).
Also change the drop-debug-info test to use llvm-link so that importing
is forced (in order to test debug info handling) and independent of
import logic changes.
Reviewers: mehdi_amini
Subscribers: mgorny, llvm-commits, aprantl
Differential Revision: https://reviews.llvm.org/D28277
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290964 91177308-0d34-0410-b5e6-96231b3b80d8
Since we type-erase the Windows GUID structure, use unsigned bytes
rather than char, which may be signed (-fsigned-char). NFC
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290765 91177308-0d34-0410-b5e6-96231b3b80d8
The Bitstream reader and writer are limited to handle a "size_t" at
most, which means that we can't backpatch and read back a 64bits
value on 32 bits platform.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290693 91177308-0d34-0410-b5e6-96231b3b80d8
This index record the position for each metadata record in
the bitcode, so that the reader will be able to lazy-load
on demand each individual record.
We also make sure that every abbrev is emitted upfront so
that the block can be skipped while reading.
I don't plan to commit this before having the reader
counterpart, but I figured this can be reviewed mostly
independently.
Recommit r290684 (was reverted in r290686 because a test
was broken) after adding a threshold to avoid emitting
the index when unnecessary (little amount of metadata).
This optimization "hides" a limitation of the ability
to backpatch in the bitstream: we can only backpatch
safely when the position has been flushed. So if we emit
an index for one metadata, it is possible that (part of)
the offset placeholder hasn't been flushed and the backpatch
will fail.
Differential Revision: https://reviews.llvm.org/D28083
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290690 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This index record the position for each metadata record in
the bitcode, so that the reader will be able to lazy-load
on demand each individual record.
We also make sure that every abbrev is emitted upfront so
that the block can be skipped while reading.
I don't plan to commit this before having the reader
counterpart, but I figured this can be reviewed mostly
independently.
Reviewers: pcc, tejohnson
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D28083
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290684 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds support for YAML<->DWARF for debug_info sections.
This re-lands r290147, reverted in 290148, re-landed in r290204 after fixing the issue that caused bots to fail (thank you UBSan!), and reverted again in r290209 due to failures on big endian systems.
After adding support for preserving endianness, this should be good now.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290386 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds support to the macho<->yaml tools for preserving endianness in MachO structures and DWARF data.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290381 91177308-0d34-0410-b5e6-96231b3b80d8
Each function summary has an attached list of type identifier GUIDs. The
idea is that during the regular LTO phase we would match these GUIDs to type
identifiers defined by the regular LTO module and store the resolutions in
a top-level "type identifier summary" (which will be implemented separately).
Differential Revision: https://reviews.llvm.org/D27967
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290280 91177308-0d34-0410-b5e6-96231b3b80d8
This sets USES_TERMINAL for the native llvm-config build, so that it
doesn't run at the same time as builds of other native tools (namely,
tablegen). Without this, if you're very unlucky with the timing it's
possible to be relinking libSupport as one of the tools is linking,
causing a spurious failure.
The tablegen build adopted USES_TERMINAL for this same reason in
r280748.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290271 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds support for YAML<->DWARF for debug_info sections.
This re-lands r290147, after fixing the issue that caused bots to fail (thank you UBSan!).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290204 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds support for YAML<->DWARF round tripping for pub* section data. The patch supports both GNU and non-GNU style entries.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290139 91177308-0d34-0410-b5e6-96231b3b80d8
DWARF 4 and later supports encoding the PC as an address or as as offset from the low PC. Clients using DWARFDie should be insulated from how to extract the high PC value. This function takes care of extracting the form value and looking for the correct form.
Differential Revision: https://reviews.llvm.org/D27885
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290131 91177308-0d34-0410-b5e6-96231b3b80d8
The Mach-O command line flag like "-arch armv7m" does not match the
arch name part of its llvm Triple which is "thumbv7m-apple-darwin”.
I think the best way to fix this is to have
llvm::object::MachOObjectFile::getArchTriple() optionally return the
name of the Mach-O arch flag that would be used with -arch that
matches the CPUType and CPUSubType. Then change
llvm::object::MachOUniversalBinary::ObjectForArch::getArchTypeName()
to use that and change it to getArchFlagName() as the type name is
really part of the Triple and the -arch flag name is a Mach-O thing
for a specific Triple with a specific Mcpu value.
rdar://29663637
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290001 91177308-0d34-0410-b5e6-96231b3b80d8
The original patch was broken due to some undefined behavior
as well as warnings that were triggering -Werror.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290000 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: ThinLTO needs to invoke SampleProfileLoader pass during link time in order to annotate profile correctly after module importing.
Reviewers: davidxl, mehdi_amini, tejohnson
Subscribers: pcc, davide, llvm-commits, mehdi_amini
Differential Revision: https://reviews.llvm.org/D27790
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289957 91177308-0d34-0410-b5e6-96231b3b80d8
This pass prepares a module containing type metadata for ThinLTO by splitting
it into regular and thin LTO parts if possible, and writing both parts to
a multi-module bitcode file. Modules that do not contain type metadata are
written unmodified as a single module.
All globals with type metadata are added to the regular LTO module, and
the rest are added to the thin LTO module.
Differential Revision: https://reviews.llvm.org/D27324
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289899 91177308-0d34-0410-b5e6-96231b3b80d8
This implements execute-only support for ARM code generation, which
prevents the compiler from generating data accesses to code sections.
The following changes are involved:
* Add the CodeGen option "-arm-execute-only" to the ARM code generator.
* Add the clang flag "-mexecute-only" as well as the GCC-compatible
alias "-mpure-code" to enable this option.
* When enabled, literal pools are replaced with MOVW/MOVT instructions,
with VMOV used in addition for floating-point literals. As the MOVT
instruction is required, execute-only support is only available in
Thumb mode for targets supporting ARMv8-M baseline or Thumb2.
* Jump tables are placed in data sections when in execute-only mode.
* The execute-only text section is assigned section ID 0, and is
marked as unreadable with the SHF_ARM_PURECODE flag with symbol 'y'.
This also overrides selection of ELF sections for globals.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289784 91177308-0d34-0410-b5e6-96231b3b80d8
When getting attributes it is sometimes nicer to use Optional<T> some of the time instead of magic values. I tried to cut over to only using the Optional values but it made many of the call sites very messy, so it makes sense the leave in the calls that can return a default value. Otherwise code that looks like this:
uint64_t CallColumn = Die.getAttributeValueAsAddress(DW_AT_call_line, 0);
Has to be turned into:
uint64_t CallColumn = 0;
if (auto CallColumnValue = Die.getAttributeValueAsAddress(DW_AT_call_line))
CallColumn = *CallColumnValue;
The first snippet of code looks much better. But in cases where you want an offset that may or may not be there, the following code looks better:
if (auto StmtOffset = Die.getAttributeValueAsSectionOffset(DW_AT_stmt_list)) {
// Use StmtOffset
}
Differential Revision: https://reviews.llvm.org/D27772
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289731 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
The motivation is to support better the -object_path_lto option on
Darwin. The linker needs to write down the generate object files on
disk for later use by lldb or dsymutil (debug info are not present
in the final binary). We're moving this into libLTO so that we can
be smarter when a cache is enabled and hard-link when possible
instead of duplicating the files.
Reviewers: tejohnson, deadalnix, pcc
Subscribers: dexonsmith, llvm-commits
Differential Revision: https://reviews.llvm.org/D27507
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289631 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
LinkDyLib is only used (before arg processing) to set up the default for
LinkMode. So reset LinkMode as well, and process before --link-shared or
--link-static to allow those flags to continue to override it.
Reviewers: beanz
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D27736
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289608 91177308-0d34-0410-b5e6-96231b3b80d8
since bpf instruction stream is multiple of 8 change llvm-objdump
to print decimal instruction number instead of hex address, so that
users don't have to do this math manually to match kernel verifier output
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289569 91177308-0d34-0410-b5e6-96231b3b80d8
Many places pass around a DWARFDebugInfoEntryMinimal and a DWARFUnit. It is easy to get things wrong by using the wrong DWARFUnit with a DWARFDebugInfoEntryMinimal. This patch creates a DWARFDie class that contains the DWARFUnit and DWARFDebugInfoEntryMinimal objects so that they can't get out of sync. All attribute extraction has been moved out of DWARFDebugInfoEntryMinimal and into DWARFDie. DWARFDebugInfoEntryMinimal was also renamed to DWARFDebugInfoEntry.
DWARFDie objects are temporary objects that are used by clients and contain 2 pointers that you always need to have anyway. Keeping them grouped will avoid errors and simplify many of the attribute extracting APIs by not having to pass in a DWARFUnit.
Differential Revision: https://reviews.llvm.org/D27634
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289565 91177308-0d34-0410-b5e6-96231b3b80d8
incorrect output when LLVM is built with `LLVM_BUILD_LLVM_DYLIB`.
`llvm-config` previously produced output like this
```
$ llvm-config --libfiles
/usr/lib/liblibLLVM-4.0svn.so.so
$ llvm-config --libnames
liblibLLVM-4.0svn.so.so
```
The library prefix and shared library extension were added to
the library name twice which was wrong.
I wanted to write a test cases for this but it looks like **all**
`llvm-config` tests were disabled by r260386 so I'll leave this for
now.
Subscribers: llvm-commits, tstellarAMD
Reviewers: beanz, DiamondLovesYou, axw
Differential Revision: https://reviews.llvm.org/D27393
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289488 91177308-0d34-0410-b5e6-96231b3b80d8
Since all the DWARF classes are in a DWARFYAML namespace having every class start with DWARF seems like a bit of overkill.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289080 91177308-0d34-0410-b5e6-96231b3b80d8
This abstracts the code for emitting DWARF binary from the DWARFYAML types into reusable interfaces that could be used by ELF and COFF.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288990 91177308-0d34-0410-b5e6-96231b3b80d8
This makes the dwarf2yaml code separated and reusable allowing ELF and COFF to share implementations with MachO.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288986 91177308-0d34-0410-b5e6-96231b3b80d8
Since DWARF formatting is agnostic to the object file it is stored in, it doesn't make sense for this to be in the MachOYAML implementation. Pulling it into its own namespace means we could modify the ELF and COFF YAML tools to emit DWARF as well.
In a follow-up patch I will better abstract this in obj2yaml and yaml2obj so that the DWARF bits in the tools can be re-used too.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288984 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds the starting support for encoding data from the MachO __DWARF segment. The first section supported is the __debug_str section because it is the simplest.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288774 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: The code we use to read PDBs assumed that streams we ask it to read exist, and would read memory outside a vector and crash if this wasn't the case. This would, for example, cause llvm-pdbdump to crash on PDBs generated by lld. This patch handles such cases more gracefully: the PDB reading code in LLVM now reports errors when asked to get a stream that is not present, and llvm-pdbdump will report missing streams and continue processing streams that are present.
Reviewers: ruiu, zturner
Subscribers: thakis, amccarth
Differential Revision: https://reviews.llvm.org/D27325
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288722 91177308-0d34-0410-b5e6-96231b3b80d8
The DIEUnit class represents a compile or type unit and it owns the unit DIE as an instance variable. This allows anyone with a DIE, to get the unit DIE, and then get back to its DIEUnit without adding any new ivars to the DIE class. Why was this needed? The DIE class has an Offset that is always the CU relative DIE offset, not the "offset in debug info section" as was commented in the header file (the comment has been corrected). This is great for performance because most DIE references are compile unit relative and this means most code that accessed the DIE's offset didn't need to make it into a compile unit relative offset because it already was. When we needed to emit a DW_FORM_ref_addr though, we needed to find the absolute offset of the DIE by finding the DIE's compile/type unit. This class did have the absolute debug info/type offset and could be added to the CU relative offset to compute the absolute offset. With this change we can easily get back to a DIE's DIEUnit which will have this needed offset. Prior to this is required having a DwarfDebug and required calling:
DwarfCompileUnit *DwarfDebug::lookupUnit(const DIE *CU) const;
Now we can use the DIEUnit class to do so without needing DwarfDebug. All clients now use DIEUnit objects (the DwarfDebug stack and the DwarfLinker). A follow on patch for the DWARF generator will also take advantage of this.
Differential Revision: https://reviews.llvm.org/D27170
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288399 91177308-0d34-0410-b5e6-96231b3b80d8
The assertions were wrong; we need to call getEncodingData() on the element,
not the array. While here, simplify the skipRecord() implementation for Fixed
and Char6 arrays. This is tested by the code I added to llvm-bcanalyzer
which makes sure that we can skip any record.
Differential Revision: https://reviews.llvm.org/D27241
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288315 91177308-0d34-0410-b5e6-96231b3b80d8
Maintain the command line resolutions as a map to a list of resolutions
rather than a single resolution, and apply the resolutions in the order
observed. This is not only simpler but allows us to test the scenario where
the two symbols have different resolutions.
Differential Revision: https://reviews.llvm.org/D27285
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288288 91177308-0d34-0410-b5e6-96231b3b80d8
This program is for testing features that rely on multi-module bitcode files.
It takes a multi-module bitcode file, extracts one of the modules and writes
it to the output file.
Differential Revision: https://reviews.llvm.org/D26778
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288201 91177308-0d34-0410-b5e6-96231b3b80d8
In some cases the leading headers of the file name, archive member and
architecture slice name in the output of lvm-objdump is not wanted so the
tool’s output can be directly used by scripts. This matches the -X option
of the Apple otool(1) program.
rdar://28491674
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288199 91177308-0d34-0410-b5e6-96231b3b80d8
This interface allows clients to write multiple modules to a single
bitcode file. Also introduce the llvm-cat utility which can be used
to create a bitcode file containing multiple modules.
Differential Revision: https://reviews.llvm.org/D26179
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@288195 91177308-0d34-0410-b5e6-96231b3b80d8
Undefined and weak symbols don't have a meaningful size or value.
As such, nothing should be printed for those attributes (this is
already done for the address with 'U') with the BSD format. This
matches what GNU nm does.
Note that for the POSIX.2 format [1] zero values are still
printed for the size and value. This seems in spirit with
the format strings in that specification, but is debatable.
[1] http://pubs.opengroup.org/onlinepubs/9699919799/
Differential Revision: https://reviews.llvm.org/D26936
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@287802 91177308-0d34-0410-b5e6-96231b3b80d8
-symbols prints both .symtab and .dynsym symbols for GNU style in ELF.
-dyn-symbols prints symbols looking up through hash tables. This helps validate hash tables.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@287786 91177308-0d34-0410-b5e6-96231b3b80d8
This commit makes llvm-cov avoid showing 0% (0/0) coverage for things
like file function coverage, etc. in reports and HTML output. This can happen
for files like headers that have macros but no functions. This commit makes
llvm-cov report - (0/0) instead.
rdar://29246480
Differential Revision: https://reviews.llvm.org/D26615
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@287539 91177308-0d34-0410-b5e6-96231b3b80d8
llvm-lto2.cpp has the following include chain:
llvm/LTO/Caching.h
llvm/LTO/LTO.h
llvm/CodeGen/Analysis.h
llvm/IR/CallSite.h
llvm/IR/Attributes.h
llvm/IR/Attributes.gen
This means llvm-lto2 needs to depend on intrinsics_gen.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@287434 91177308-0d34-0410-b5e6-96231b3b80d8
AnalysisWrappers.cpp has the following include chain:
llvm/Analysis/CallGraph.h
llvm/IR/CallSite.h
llvm/IR/Attributes.h
llvm/IR/Attributes.gen
This means opt needs to depend on intrinsics_gen.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@287433 91177308-0d34-0410-b5e6-96231b3b80d8
llvm-nm.cpp has the following include chain:
llvm/IR/Function.h
llvm/IR/Argument.h
llvm/IR/Attributes.h
llvm/IR/Attributes.gen
This means llvm-nm needs to depend on intrinsics_gen.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@287432 91177308-0d34-0410-b5e6-96231b3b80d8
llvm-link.cpp has the following include chain:
llvm/Bitcode/BitcodeWriter.h
llvm/IR/ModuleSummaryIndex.h
llvm/IR/Module.h
llvm/IR/Function.h
llvm/IR/Argument.h
llvm/IR/Attributes.h
llvm/IR/Attributes.gen
This means llvm-link needs to depend on intrinsics_gen.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@287431 91177308-0d34-0410-b5e6-96231b3b80d8
llvm-extract.cpp has the following include chain:
llvm/Bitcode/BitcodeWriterPass.h
llvm/IR/PassManager.h
llvm/IR/Function.h
llvm/IR/Argument.h
llvm/IR/Attributes.h
llvm/IR/Attributes.gen
This means llvm-extract needs to depend on intrinsics_gen.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@287430 91177308-0d34-0410-b5e6-96231b3b80d8
llvm-dwp.cpp has the following include chain:
llvm/CodeGen/AsmPrinter.h
llvm/CodeGen/MachineFunctionPass.h
llvm/CodeGen/MachineFunction.h
llvm/CodeGen/MachineBasicBlock.h
llvm/CodeGen/MachineInstr.h
llvm/Analysis/AliasAnalysis.h
llvm/IR/CallSite.h
llvm/IR/Attributes.h
llvm/IR/Attributes.gen
This means llvm-dwp needs to depend on intrinsics_gen.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@287429 91177308-0d34-0410-b5e6-96231b3b80d8
llvm-dis.cpp has the following include chain:
llvm/Bitcode/BitcodeReader.h
llvm/IR/ModuleSummaryIndex.h
llvm/IR/Module.h
llvm/IR/Function.h
llvm/IR/Argument.h
llvm/IR/Attributes.h
llvm/IR/Attributes.gen
This means llvm-dis needs to depend on intrinsics_gen.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@287428 91177308-0d34-0410-b5e6-96231b3b80d8
llvm-diff.cpp has the following include chain:
llvm/IR/Module.h
llvm/IR/Function.h
llvm/IR/Argument.h
llvm/IR/Attributes.h
llvm/IR/Attributes.gen
This means llvm-diff needs to depend on intrinsics_gen.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@287427 91177308-0d34-0410-b5e6-96231b3b80d8
llvm-stress.cpp has the following include chain:
llvm/Analysis/CallGraphSCCPass.h
llvm/Analysis/CallGraph.h
llvm/IR/CallSite.h
llvm/IR/Attributes.h
llvm/IR/Attributes.gen
This means llvm-stress needs to depend on intrinsics_gen.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@287426 91177308-0d34-0410-b5e6-96231b3b80d8
TestPasses.cpp has the following include chain:
llvm/IR/InstVisitor.h
llvm/IR/CallSite.h
llvm/IR/Attributes.h
llvm/IR/Attributes.gen
This means bugpoint-passes needs to depend on intrinsics_gen.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@287425 91177308-0d34-0410-b5e6-96231b3b80d8
llvm-bcanalyzer.cpp has the following include chain:
llvm/Bitcode/BitcodeReader.h
llvm/IR/ModuleSummaryIndex.h
llvm/IR/Module.h
llvm/IR/Function.h
llvm/IR/Argument.h
llvm/IR/Attributes.h
llvm/IR/Attributes.gen
This means llvm-bcanalyzer needs to depend on intrinsics_gen.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@287424 91177308-0d34-0410-b5e6-96231b3b80d8
llvm-as.cpp has the following include chain:
llvm/Bitcode/BitcodeWriter.h
llvm/IR/ModuleSummaryIndex.h
llvm/IR/Module.h
llvm/IR/Function.h
llvm/IR/Argument.h
llvm/IR/Attributes.h
llvm/IR/Attributes.gen
This means llvm-as needs to depend on intrinsics_gen.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@287423 91177308-0d34-0410-b5e6-96231b3b80d8
llc.cpp has the following include chain:
llvm/Analysis/TargetLibraryInfo.h
llvm/IR/Function.h
llvm/IR/Argument.h
llvm/IR/Attributes.h
llvm/IR/Attributes.gen
This means llc needs to depend on intrinsics_gen.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@287422 91177308-0d34-0410-b5e6-96231b3b80d8
Messed up in r287420, it isn't just lli, but also but lli-child-target that need to depend on intrinsics_gen.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@287421 91177308-0d34-0410-b5e6-96231b3b80d8
ChildTarget.cpp has the following include chain:
llvm/ExecutionEngine/Orc/OrcABISupport.h
llvm/ExecutionEngine/Orc/IndirectionUtils.h
llvm/IR/IRBuilder.h
llvm/IR/ConstantFolder.h
llvm/IR/InstrTypes.h
llvm/IR/Attributes.h
llvm/IR/Attributes.gen
This means lli needs to depend on intrinsics_gen.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@287420 91177308-0d34-0410-b5e6-96231b3b80d8
DwarfLinker.cpp has the following include chain:
llvm/CodeGen/AsmPrinter.h
llvm/CodeGen/MachineFunctionPass.h
llvm/CodeGen/MachineFunction.h
llvm/CodeGen/MachineBasicBlock.h
llvm/CodeGen/MachineInstr.h
llvm/Analysis/AliasAnalysis.h
llvm/IR/CallSite.h
llvm/IR/Attributes.h
llvm/IR/Attributes.gen
This means llvm-dsymutil needs to depend on intrinsics_gen.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@287419 91177308-0d34-0410-b5e6-96231b3b80d8
verify-uselistorder.cpp has the following include chain:
llvm/Bitcode/BitcodeReader.h
llvm/IR/ModuleSummaryIndex.h
llvm/IR/Module.h
llvm/IR/Function.h
llvm/IR/Argument.h
llvm/IR/Attributes.h
llvm/IR/Attributes.gen
This means verify-uselistorder needs to depend on intrinsics_gen.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@287405 91177308-0d34-0410-b5e6-96231b3b80d8
