This allows later passes (in particular InstCombine) to optimize more
cases.
One that's important to us is `memcmp(p, q, constant) < 0` and memcmp(p, q, constant) > 0.
llvm-svn: 364412
This reverts r364254 (git commit 545f001d1b)
This change causes some llvm-obcopy tests to fail with valgrind.
Following is the output for basic-keep.test
Command Output (stderr):
--
==107406== Conditional jump or move depends on uninitialised value(s)
==107406== at 0x1A30DD: executeObjcopy(llvm::objcopy::CopyConfig const&) (llvm-objcopy.cpp:235)
==107406== by 0x1A3935: main (llvm-objcopy.cpp:294)
llvm-svn: 364379
This reverts r364263 (git commit 81eb828405)
This commit is related to r364254 which is causing some llvm-objcopy tests
to fail with valgrind.
Error:
Conditional jump or move depends on uninitialised value(s)
llvm-svn: 364378
Summary:
The MinGW driver for lld does not support the --version-script option.
For GNU ld, it's a no-op since LLVM.dll exports all symbols.
Reviewers: srhines, mstorsjo
Subscribers: mgorny, fedor.sergeev, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D63743
llvm-svn: 364343
Summary:
The directive defines a symbol as an group/local memory (LDS) symbol.
LDS symbols behave similar to common symbols for the purposes of ELF,
using the processor-specific SHN_AMDGPU_LDS as section index.
It is the linker and/or runtime loader's job to "instantiate" LDS symbols
and resolve relocations that reference them.
It is not possible to initialize LDS memory (not even zero-initialize
as for .bss).
We want to be able to link together objects -- starting with relocatable
objects, but possible expanding to shared objects in the future -- that
access LDS memory in a flexible way.
LDS memory is in an address space that is entirely separate from the
address space that contains the program image (code and normal data),
so having program segments for it doesn't really make sense.
Furthermore, we want to be able to compile multiple kernels in a
compilation unit which have disjoint use of LDS memory. In that case,
we may want to place LDS symbols differently for different kernels
to save memory (LDS memory is very limited and physically private to
each kernel invocation), so we can't simply place LDS symbols in a
.lds section.
Hence this solution where LDS symbols always stay undefined.
Change-Id: I08cbc37a7c0c32f53f7b6123aa0afc91dbc1748f
Reviewers: arsenm, rampitec, t-tye, b-sumner, jsjodin
Subscribers: kzhuravl, jvesely, wdng, yaxunl, dstuttard, tpr, rupprecht, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D61493
llvm-svn: 364296
The patch teaches yaml2obj/obj2yaml to support parsing/dumping
the sections and symbols with the same name.
A special suffix is added to a name to make it unique.
Differential revision: https://reviews.llvm.org/D63596
llvm-svn: 364282
Summary:
Use an enum instead of string to hold the output file format in Config.InputFormat and Config.OutputFormat. It's essential to support other output file formats other than ELF.
Reviewers: espindola, alexshap, rupprecht, jhenderson
Reviewed By: rupprecht, jhenderson
Subscribers: jyknight, compnerd, emaste, arichardson, fedor.sergeev, jakehehrlich, MaskRay, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D63239
llvm-svn: 364254
This command prints a description of the referenced function's stack frame.
For each formal parameter and local variable, the tool prints:
- function name
- variable name
- file/line of declaration
- FP-relative variable location (if available)
- size in bytes
- HWASAN tag offset
This information will be used by the HWASAN runtime to identify local
variables in UAR reports.
Differential Revision: https://reviews.llvm.org/D63468
llvm-svn: 364225
-d code.
Summary:
Move it into `main` function so the checking is effective for all actions
user may do with llvm-objdump; notably, -r and -s in addition to existing -d.
Match GNU behavior.
Reviewers: jhenderson, grimar, MaskRay, rupprecht
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D63631
llvm-svn: 364118
This patch teaches the bottleneck analysis how to identify and print the most
expensive sequence of instructions according to the simulation. Fixes PR37494.
The goal is to help users identify the sequence of instruction which is most
critical for performance.
A dependency graph is internally used by the bottleneck analysis to describe
data dependencies and processor resource interferences between instructions.
There is one node in the graph for every instruction in the input assembly
sequence. The number of nodes in the graph is independent from the number of
iterations simulated by the tool. It means that a single node of the graph
represents all the possible instances of a same instruction contributed by the
simulated iterations.
Edges are dynamically "discovered" by the bottleneck analysis by observing
instruction state transitions and "backend pressure increase" events generated
by the Execute stage. Information from the events is used to identify critical
dependencies, and materialize edges in the graph. A dependency edge is uniquely
identified by a pair of node identifiers plus an instance of struct
DependencyEdge::Dependency (which provides more details about the actual
dependency kind).
The bottleneck analysis internally ranks dependency edges based on their impact
on the runtime (see field DependencyEdge::Dependency::Cost). To this end, each
edge of the graph has an associated cost. By default, the cost of an edge is a
function of its latency (in cycles). In practice, the cost of an edge is also a
function of the number of cycles where the dependency has been seen as
'contributing to backend pressure increases'. The idea is that the higher the
cost of an edge, the higher is the impact of the dependency on performance. To
put it in another way, the cost of an edge is a measure of criticality for
performance.
Note how a same edge may be found in multiple iteration of the simulated loop.
The logic that adds new edges to the graph checks if an equivalent dependency
already exists (duplicate edges are not allowed). If an equivalent dependency
edge is found, field DependencyEdge::Frequency of that edge is incremented by
one, and the new cost is cumulatively added to the existing edge cost.
At the end of simulation, costs are propagated to nodes through the edges of the
graph. The goal is to identify a critical sequence from a node of the root-set
(composed by node of the graph with no predecessors) to a 'sink node' with no
successors. Note that the graph is intentionally kept acyclic to minimize the
complexity of the critical sequence computation algorithm (complexity is
currently linear in the number of nodes in the graph).
The critical path is finally computed as a sequence of dependency edges. For
edges describing processor resource interferences, the view also prints a
so-called "interference probability" value (by dividing field
DependencyEdge::Frequency by the total number of iterations).
Examples of critical sequence computations can be found in tests added/modified
by this patch.
On output streams that support colored output, instructions from the critical
sequence are rendered with a different color.
Strictly speaking the analysis conducted by the bottleneck analysis view is not
a critical path analysis. The cost of an edge doesn't only depend on the
dependency latency. More importantly, the cost of a same edge may be computed
differently by different iterations.
The number of dependencies is discovered dynamically based on the events
generated by the simulator. However, their number is not fixed. This is
especially true for edges that model processor resource interferences; an
interference may not occur in every iteration. For that reason, it makes sense
to also print out a "probability of interference".
By construction, the accuracy of this analysis (as always) is strongly dependent
on the simulation (and therefore the quality of the information available in the
scheduling model).
That being said, the critical sequence effectively identifies a performance
criticality. Instructions from that sequence are expected to have a very big
impact on performance. So, users can take advantage of this information to focus
their attention on specific interactions between instructions.
In my experience, it works quite well in practice, and produces useful
output (in a reasonable amount time).
Differential Revision: https://reviews.llvm.org/D63543
llvm-svn: 364045
Many LLVM-based tools already support response files (i.e. files
containing a list of options, specified with '@'). This change simply
updates the documentation and help text for some of these tools to
include it. I haven't attempted to fix all tools, just a selection that
I am interested in.
I've taken the opportunity to add some tests for --help behaviour, where
they were missing. We could expand these tests, but I don't think that's
within scope of this patch.
This fixes https://bugs.llvm.org/show_bug.cgi?id=42233 and
https://bugs.llvm.org/show_bug.cgi?id=42236.
Reviewed by: grimar, MaskRay, jkorous
Differential Revision: https://reviews.llvm.org/D63597
llvm-svn: 364036
--help and -h are automatically supported by the command-line parser,
unless overridden by the tool. The behaviour of the PrintHelpMessage
being used for -h prior to this patch is subtly different to that
provided by --help automatically (it omits certain elements of help text
and options, such as --help-list), so overriding the default is not
desirable, without good reason. This patch removes the explicit
specification of -h and its behaviour, so that the default behaviour is
used.
Reviewed by: hintonda
Differential Revision: https://reviews.llvm.org/D63565
llvm-svn: 364029
Summary: Build the string table using StringTableBuilder, reassign symbol indices, and update symbol indices in relocations to allow adding/modifying/removing symbols from the object.
Reviewers: alexshap, rupprecht, jhenderson
Reviewed By: alexshap
Subscribers: mgorny, jakehehrlich, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D63309
llvm-svn: 364000
ELFState<ELFT>::addSymbols method looks a bit strange.
User code have to create the destination symbols vector outside,
add a null symbol and then pass it to addSymbols when it seems
the more natural logic is to isolate all work with symbols inside some
function, build the list right there and return it.
Differential revision: https://reviews.llvm.org/D63493
llvm-svn: 363930
The ARMDisassembler changes allow changing between ARM and Thumb mode
based on the MCSubtargetInfo, rather than the Target, which simplifies
the other changes a bit.
I'm not really happy with adding more target-specific logic to
tools/llvm-objdump/, but there isn't any easy way around it: the logic
in question specifically applies to disassembling an object file, and
that code simply isn't located in lib/Target, at least at the moment.
Differential Revision: https://reviews.llvm.org/D60927
llvm-svn: 363903
Turns out this worked on my machine because I still had VS2017 installed, but
it didn't actually work in general.
Since the extension is unmaintained and MS is doing their own LLVM toolset
integration for VS2019, let's just revert.
llvm-svn: 363768
Summary:
Historically llvm-objdump prints the path to a dylib as well as the
dylib's compatibility version and current version number. This change
extends this information by adding the kind of dylib load: weak,
reexport, etc.
rdar://51383512
Reviewers: pete, lhames
Reviewed By: pete
Subscribers: rupprecht, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62866
llvm-svn: 363746
Some versions of the Visual C++ 2015 runtime have line tables with the
subsection kind of 0x800000F2. In cvinfo.h, 0x80000000 is documented to
be DEBUG_S_IGNORE. This appears to implement the intended behavior.
llvm-svn: 363724
1) `-x foo` currently dumps one `foo`. This change makes it dump all `foo`.
2) `-x foo -x foo` currently dumps `foo` twice. This change makes it dump `foo` once.
In addition, if foo has section index 9, `-x foo -x 9` dumps `foo` once.
3) Give a warning instead of an error if `foo` does not exist.
The new behaviors match GNU readelf.
Also, print a new line as a separator between two section dumps.
GNU readelf uses two lines, but one seems good enough.
Reviewed By: grimar, jhenderson
Differential Revision: https://reviews.llvm.org/D63475
llvm-svn: 363683
This patch slightly refactors data structures internally used by the bottleneck
analysis to track data and resource dependencies.
This patch also updates methods used to print out information about dependency
edges when in debug mode.
This is the last of a sequence of commits done in preparation for an upcoming
patch that fixes PR37494. No functional change intended.
llvm-svn: 363677
Summary: Implements bug [[ https://bugs.llvm.org/show_bug.cgi?id=42204 | 42204 ]]. llvm-strip now warns when the same input file is used more than once, and errors when stdin is used more than once.
Reviewers: jhenderson, rupprecht, espindola, alexshap
Reviewed By: jhenderson, rupprecht
Subscribers: emaste, arichardson, jakehehrlich, MaskRay, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D63122
llvm-svn: 363638
Use -fsave-optimization-record=<format> to specify a different format
than the default, which is YAML.
For now, only YAML is supported.
llvm-svn: 363573
Summary:
Currently, MachOWriter::writeSectionData writes dummy data (0xdeadbeef) to fill section data areas in the file even if the section is a virtual one. Since virtual sections don't occupy any space in the file, writing dummy data could results the "OS.tell() - fileStart <= Sec.offset" assertion failure.
This patch fixes the bug by simply not writing any dummy data for virtual sections.
Reviewers: beanz, jhenderson, rupprecht, alexshap
Reviewed By: alexshap
Subscribers: compnerd, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62991
llvm-svn: 363525
Summary:
The "sparc"/"sparcel" architectures appears in ArchMap (used by -B option) but not in OutputFormatMap (used by -I/-O option). Add their targets into OutputFormatMap for consistency.
Note that AFAIK there're no targets for 32-bit little-endian SPARC ("elf32-sparcel") in GNU binutils.
Reviewers: espindola, alexshap, rupprecht, jhenderson, compnerd, jakehehrlich
Reviewed By: jhenderson, compnerd, jakehehrlich
Subscribers: jyknight, emaste, arichardson, fedor.sergeev, jakehehrlich, MaskRay, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D63238
llvm-svn: 363524
* Add a common function to setup opt-remarks
* Rename common options to the same names
* Add error types to distinguish between file errors and regex errors
llvm-svn: 363415
LLD test case will be fixed in a following commit.
Original commit message:
[yaml2obj] - Allow setting custom section types for implicit sections.
We were hardcoding the final section type for sections that
are usually implicit. The patch fixes that.
This also fixes a few issues in existent test cases and removes
one precompiled object.
Differential revision: https://reviews.llvm.org/D63267
llvm-svn: 363401
The docs and help text for --show-parents and --show-children were a bit
inconsistent. The help text claimed they had an effect when "=<offset>"
was used, whereas the doc said it had an effect when "--find" or
"--name" were used. This change changes the doc to mention "=<offset>"
and removes this reference from the help text, to avoid having a very
long description in the help text (it still says "when selectively
printing entries").
Reviewed by: JDevlieghere, aprantl
Differential Revision: https://reviews.llvm.org/D63275
llvm-svn: 363380
We were hardcoding the final section type for sections that
are usually implicit. The patch fixes that.
This also fixes a few issues in existent test cases and removes
one precompiled object.
Differential revision: https://reviews.llvm.org/D63267
llvm-svn: 363377
If dynamic table is missing, output "dynamic strtab not found'. If the index is
out of range, output "Invalid Offset<..>".
https://bugs.llvm.org/show_bug.cgi?id=40807
Reviewed by: jhenderson, grimar, MaskRay
Differential Revision: https://reviews.llvm.org/D63084
Patch by Yuanfang Chen.
llvm-svn: 363374
Despite the fact that .strtab is non-allocatable,
there is no reason to disallow setting the custom address
for it.
The patch also adds a test case showing we can set any address
we want for other implicit sections.
Differential revision: https://reviews.llvm.org/D63137
llvm-svn: 363368
With this patch we get ability to set any flags we want
for implicit sections defined in YAML.
Differential revision: https://reviews.llvm.org/D63136
llvm-svn: 363367
Summary: Tidied up errors during command line parsing to be more consistent with the rest of llvm-objcopy errors.
Reviewers: jhenderson, rupprecht, espindola, alexshap
Reviewed By: jhenderson, rupprecht
Subscribers: emaste, arichardson, MaskRay, llvm-commits, jakehehrlich
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62973
llvm-svn: 363350
Summary: AFAIK, the "sparc" target is big endian and the target for 32-bit little-endian SPARC is denoted as "sparcel". This patch fixes the endianness of "sparc" target and adds "sparcel" target for 32-bit little-endian SPARC.
Reviewers: espindola, alexshap, rupprecht, jhenderson
Reviewed By: jhenderson
Subscribers: jyknight, emaste, arichardson, fedor.sergeev, jakehehrlich, MaskRay, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D63251
llvm-svn: 363336
* Add a common function to setup opt-remarks
* Rename common options to the same names
* Add error types to distinguish between file errors and regex errors
llvm-svn: 363328
Filter out irrelevant options
New output:
OVERVIEW: llvm extractor
USAGE: llvm-extract [options] <input bitcode file>
OPTIONS:
Generic Options:
--help - Display available options (--help-hidden for more)
--help-list - Display list of available options (--help-list-hidden for more)
--version - Display the version of this program
llvm-extract Options:
--alias=<alias> - Specify alias to extract
--bb=<function:bb> - Specify <function, basic block> pairs to extract
--delete - Delete specified Globals from Module
-f - Enable binary output on terminals
--func=<function> - Specify function to extract
--glob=<global> - Specify global to extract
-o=<filename> - Specify output filename
--ralias=<ralias> - Specify alias(es) to extract using a regular expression
--recursive - Recursively extract all called functions
--rfunc=<rfunction> - Specify function(s) to extract using a regular expression
--rglob=<rglobal> - Specify global(s) to extract using a regular expression
Differential Revision: https://reviews.llvm.org/D62511
llvm-svn: 363201
Summary:
Use llvm::fouts() as the default stream for outputing. No new stream
should be constructed to output at the same time.
https://bugs.llvm.org/show_bug.cgi?id=42140
Reviewers: jhenderson, grimar, MaskRay, phosek, rupprecht
Reviewed By: rupprecht
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D63115
Patch by Yuanfang Chen!
llvm-svn: 363198
This was using its own, outdated list of possible captures. This was
at minimum not catching cmpxchg and addrspacecast captures.
One change is now any volatile access is treated as capturing. The
test coverage for this pass is quite inadequate, but this required
removing volatile in the lifetime capture test.
Also fixes some infrastructure issues to allow running just the IR
pass.
Fixes bug 42238.
llvm-svn: 363169
r363016 let lld-link and llvm-lib share the /machine: parsing code.
This lets llvm-cvtres share it as well.
Making llvm-cvtres depend on llvm-lib seemed a bit strange (it doesn't
need llvm-lib's dependencies on BinaryFormat and BitReader) and I
couldn't find a good place to put this code. Since it's just a few
lines, put it in lib/Object for now.
Differential Revision: https://reviews.llvm.org/D63120
llvm-svn: 363144
Dependent libraries support for the legacy api was committed in a
broken state (see: https://reviews.llvm.org/D60274). This was missed
due to the painful nature of having to integrate the changes into a
linker in order to test. This change implements support for dependent
libraries in the legacy LTO api:
- I have removed the current api function, which returns a single
string, and added functions to access each dependent library
specifier individually.
- To reduce the testing pain, I have made the api functions as thin as
possible to maximize coverage from llvm-lto.
- When doing ThinLTO the system linker will load the modules lazily
when scanning the input files. Unfortunately, when modules are
lazily loaded there is no access to module level named metadata. To
fix this I have added api functions that allow querying the IRSymtab
for the dependent libraries. I hope to expand the api in the future
so that, eventually, all the information needed by a client linker
during scan can be retrieved from the IRSymtab.
Differential Revision: https://reviews.llvm.org/D62935
llvm-svn: 363140
The --print-size help text and documentation claimed that the size was
printed instead of the address, but this is incorrect. It is printed as
well as the address. This patch fixes this issue.
Reviewed by: MaskRay, mtrent, ruiu
Differential Revision: https://reviews.llvm.org/D63142
llvm-svn: 363136
There was a typo in the --ignore-case help text that was copied into the
llvm-dwarfdump command-guide. Additionally, this patch simplifies the
wording, since it was unnecessarily verbose: the switch applies for
searching in general and doesn't need explicitly stating different
search modes (which might go out-of-date as options are added or
removed).
Reviwed by: JDevlieghere
Differential Revision: https://reviews.llvm.org/D63133
llvm-svn: 363066
For lld, pass in Config->Timestamp (which is set based on lld's
/timestamp: and /Brepro flags). Since the writeWindowsResourceCOFF()
data is only used in-memory by LLD and the obj's timestamp isn't used
for anything in the output, this doesn't change behavior.
For llvm-cvtres, add an optional /timestamp: parameter, and use the
current behavior of calling time() if the parameter is not passed in.
This doesn't really change observable behavior (unless someone passes
/timestamp: to llvm-cvtres, which wasn't possible before), but it
removes the last unqualified call to time() from llvm/lib, which seems
like a good thing.
Differential Revision: https://reviews.llvm.org/D63116
llvm-svn: 363050
-o is in the documentation, but not in the llvm-dwarfdump help text.
This patch adds it by inverting the -o and --out-file aliasing. It also
removes --out-file from the documentation, since we don't really want
people to be using this switch in practice.
Reviewed by: aprantl, JDevlieghere, dblaikie
Differential Revision: https://reviews.llvm.org/D63013
llvm-svn: 363044
Allow using both custom numeric and string values for Link field of the
dynamic and regular symbol tables.
Differential revision: https://reviews.llvm.org/D63077
llvm-svn: 363042
This makes the interface simpler and more consistent with the interface for
.dSYM files and fixes a bug where llvm-symbolizer would not read the dwp if
it was asked to symbolize data before symbolizing code.
Differential Revision: https://reviews.llvm.org/D63114
llvm-svn: 363025
Summary:
When llvm-objcopy sorts sections during finalization, it only sorts based on the offset, which can cause the group section to come after the sections it contains. This causes link failures when using gold to link objects created by llvm-objcopy.
Fix this for now by copying GNU objcopy's behavior of placing SHT_GROUP sections first. In the future, we may want to remove this sorting entirely to more closely preserve the input file layout.
This fixes https://bugs.llvm.org/show_bug.cgi?id=42052.
Reviewers: jakehehrlich, jhenderson, MaskRay, espindola, alexshap
Reviewed By: MaskRay
Subscribers: phuongtrang148993, emaste, arichardson, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62620
llvm-svn: 362973
Bottleneck Analysis is one of the many views available in llvm-mca. Therefore,
it should be enabled when flag -all-views is passed in input to the tool.
llvm-svn: 362964
This is a follow-up for D62809.
Content and Size fields should be optional as was discussed in comments
of the D62809's thread. With that, we can describe a specific string table and
symbol table sections in a more correct way and also show appropriate errors.
The patch adds lots of test cases where the behavior is described in details.
Differential revision: https://reviews.llvm.org/D62957
llvm-svn: 362931
We have a code in buildSectionIndex() that adds implicit sections:
// Add special sections after input sections, if necessary.
for (StringRef Name : implicitSectionNames())
if (SN2I.addName(Name, SecNo)) {
// Account for this section, since it wasn't in the Doc
++SecNo;
DotShStrtab.add(Name);
}
The problem arises when .dynsym is specified explicitly and no
DynamicSymbols is used. In that case, we do not add
.dynstr implicitly and will assert later when will try to set Link
for .dynsym.
Seems, in this case, reasonable behavior is to allow Link field to be zero.
This is what this patch does.
Differential revision: https://reviews.llvm.org/D63001
llvm-svn: 362929
Summary:
Recompute and update offset/size fields so that we can implement llvm-objcopy options like --only-section.
This patch is the first step and focuses on supporting load commands that covered by existing tests: executable files and
dynamic libraries are not supported.
Reviewers: alexshap, rupprecht, jhenderson
Reviewed By: alexshap, rupprecht
Subscribers: compnerd, jakehehrlich, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62652
llvm-svn: 362863
Summary:
This fixes the bugzilla id,41862 to support dealing with checking
stop address against start address to support this not being a
proper object to check the disasembly against like gnu objdump
currently does.
Reviewers: jakehehrlich, rupprecht, echristo, jhenderson, grimar
Reviewed By: jhenderson
Subscribers: MaskRay, smeenai, rupprecht, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D61969
Patch by Nicholas Krause!
llvm-svn: 362847
Displays the architecture names of an input file.
Unknown architectures are represented by unknown(cputype,cpusubtype).
Patch by Anusha Basana <anusha.basana@gmail.com>
Differential Revision: https://reviews.llvm.org/D62753
llvm-svn: 362840
This implements the functionality described in
https://lld.llvm.org/Partitions.html. It works as follows:
- Reads the section headers using the ELF header at file offset 0;
- If extracting a loadable partition:
- Finds the section containing the required partition ELF header by looking it up in the section table;
- Reads the ELF and program headers from the section.
- If extracting the main partition:
- Reads the ELF and program headers from file offset 0.
- Filters the section table according to which sections are in the program headers that it read:
- If ParentSegment != nullptr or section is not SHF_ALLOC, then it goes in.
- Sections containing partition ELF headers or program headers are excluded as there are no headers for these in ordinary ELF files.
Differential Revision: https://reviews.llvm.org/D62364
llvm-svn: 362818
Before this patch we used either a single thread, or the number of
hardware threads available, effectively ignoring the number of threads
specified on the command line.
llvm-svn: 362815
This is https://bugs.llvm.org/show_bug.cgi?id=42122.
If an object file has a size less than program header's file [offset + size]
(i.e. if we have overflow), llvm-objcopy crashes instead of reporting a
error.
The patch fixes this issue.
Differential revision: https://reviews.llvm.org/D62898
llvm-svn: 362778
This is a refactoring follow-up for D62809
"Change how we handle implicit sections.".
It allows to simplify the code.
Differential revision: https://reviews.llvm.org/D62912
llvm-svn: 362777
Patch which introduces a target-independent framework for generating
hardware loops at the IR level. Most of the code has been taken from
PowerPC CTRLoops and PowerPC has been ported over to use this generic
pass. The target dependent parts have been moved into
TargetTransformInfo, via isHardwareLoopProfitable, with
HardwareLoopInfo introduced to transfer information from the backend.
Three generic intrinsics have been introduced:
- void @llvm.set_loop_iterations
Takes as a single operand, the number of iterations to be executed.
- i1 @llvm.loop_decrement(anyint)
Takes the maximum number of elements processed in an iteration of
the loop body and subtracts this from the total count. Returns
false when the loop should exit.
- anyint @llvm.loop_decrement_reg(anyint, anyint)
Takes the number of elements remaining to be processed as well as
the maximum numbe of elements processed in an iteration of the loop
body. Returns the updated number of elements remaining.
llvm-svn: 362774
This patch implements the "CREATE_THIN" MRI script command, allowing thin archives to be created via MRI scripts.
Differential Revision: https://reviews.llvm.org/D62919
llvm-svn: 362704
When running dsymutil on a fat binary, we use temporary files in a small
vector of size four. When processing more than 4 architectures, this
resulted in a user-after-move, because the temporary files got moved to
the heap. Instead of storing an optional temp file, we now use a unique
pointer, so the location of the actual temp file doesn't change.
We could test this by checking in 5 binaries for 5 different
architectures, but this seems wasteful, especially since the number of
elements in the small vector is arbitrary.
llvm-svn: 362621
Clement Courbet