| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 340065
|
| |
|
|
|
|
|
|
|
|
| |
class Scheduler should not know anything of hardware event listeners and
hardware stall events (HWStallEvent). HWStallEvent objects should only be
constructed by pipeline stages to notify listeners of hardware events.
No functional change intended.
llvm-svn: 340036
|
| |
|
|
|
|
|
|
| |
Fixes build breakage of llvm-mc-assemble-fuzzer introduced by r332749.
Fix provided by pbhatu (Pratik Bhatu)
llvm-svn: 339981
|
| |
|
|
|
|
| |
Reported by buildbot `clang-with-lto-ubuntu` ( build #9858 ).
llvm-svn: 339928
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch changes how instruction execution is orchestrated by the Pipeline.
In particular, this patch makes it more explicit how instructions transition
through the various pipeline stages during execution.
The main goal is to simplify both the stage API and the Pipeline execution. At
the same time, this patch fixes some design issues which are currently latent,
but that are likely to cause problems in future if people start defining custom
pipelines.
The new design assumes that each pipeline stage knows the "next-in-sequence".
The Stage API has gained three new methods:
- isAvailable(IR)
- checkNextStage(IR)
- moveToTheNextStage(IR).
An instruction IR can be executed by a Stage if method `Stage::isAvailable(IR)`
returns true.
Instructions can move to next stages using method moveToTheNextStage(IR).
An instruction cannot be moved to the next stage if method checkNextStage(IR)
(called on the current stage) returns false.
Stages are now responsible for moving instructions to the next stage in sequence
if necessary.
Instructions are allowed to transition through multiple stages during a single
cycle (as long as stages are available, and as long as all the calls to
`checkNextStage(IR)` returns true).
Methods `Stage::preExecute()` and `Stage::postExecute()` have now become
redundant, and those are removed by this patch.
Method Pipeline::runCycle() is now simpler, and it correctly visits stages
on every begin/end of cycle.
Other changes:
- DispatchStage no longer requires a reference to the Scheduler.
- ExecuteStage no longer needs to directly interact with the
RetireControlUnit. Instead, executed instructions are now directly moved to the
next stage (i.e. the retire stage).
- RetireStage gained an execute method. This allowed us to remove the
dependency with the RCU in ExecuteStage.
- FecthStage now updates the "program counter" during cycleBegin() (i.e.
before we start executing new instructions).
- We no longer need Stage::Status to be returned by method execute(). It has
been dropped in favor of a more lightweight llvm::Error.
Overally, I measured a ~11% performance gain w.r.t. the previous design. I also
think that the Stage interface is probably easier to read now. That being said,
code comments have to be improved, and I plan to do it in a follow-up patch.
Differential revision: https://reviews.llvm.org/D50849
llvm-svn: 339923
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: [llvm-strip] Preserve access/modification timestamps when -p is used.
Reviewers: jakehehrlich, jhenderson, alexshap
Reviewed By: jhenderson
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D50744
llvm-svn: 339921
|
| |
|
|
|
|
|
|
|
|
|
|
| |
improve the modularity of the Pipeline. NFCI
The main difference is that now `cycleStart()` and `cycleEnd()` return an
llvm::Error.
This patch implements a few minor style changes, and adds missing 'const' to
some methods.
llvm-svn: 339885
|
| |
|
|
|
|
|
| |
That change allows using numeric values for Link field.
It is consistent with the code for another fields in this method.
llvm-svn: 339873
|
| |
|
|
|
|
|
| |
This simplifies the code allowing to set the sh_info
for relocations sections. And adds a missing test.
llvm-svn: 339870
|
| |
|
|
| |
llvm-svn: 339823
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
field.
This allows to set custom Info field value for SHT_GROUP sections.
It is useful to allow this because we would be able to replace at least one binary
object committed in LLD and replace it with the yaml2obj based test.
Differential revision: https://reviews.llvm.org/D50776
llvm-svn: 339772
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
resource mask (an uint64_t value) to unsigned.
This patch fixes a regression introduced at revision 338702.
A processor resource mask was incorrectly implicitly truncated to an unsigned
quantity. Later on, the truncated mask was used to initialize an element of a
vector of processor resource descriptors.
On targets with more than 32 processor resources, some elements of the vector
are left uninitialized. As a consequence, this bug might have eventually caused
a crash due to null dereference in the Scheduler.
This patch fixes PR38575, and adds a test for it.
llvm-svn: 339768
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Currently, it is possible to use yaml2obj for producing SHT_GROUP sections
of type GRP_COMDAT. For LLD test case I need to produce an object with
a broken (different from GRP_COMDAT) type.
The patch teaches tool to do such things.
Differential revision: https://reviews.llvm.org/D50761
llvm-svn: 339764
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
sys::fs::setLastModificationAndAccessTime.
Summary:
Add an overload to sys::fs::setLastModificationAndAccessTime that allows setting last access and modification times separately. This will allow tools to use this API when they want to preserve both the access and modification times from an input file, which may be different.
Also note that both the POSIX (futimens/futimes) and Windows (SetFileTime) APIs take the two timestamps in the order of (1) access (2) modification time, so this renames the method to "setLastAccessAndModificationTime" to make it clear which timestamp is which.
For existing callers, the 1-arg overload just sets both timestamps to the same thing.
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D50521
llvm-svn: 339628
|
| |
|
|
| |
llvm-svn: 339616
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch introduces error handling to propagate the errors from llvm-mca library classes (or what will become library classes) up to the driver. This patch also introduces an enum to make clearer the intention of the return value for Stage::execute.
This supports PR38101.
Reviewers: andreadb, courbet, RKSimon
Reviewed By: andreadb
Subscribers: llvm-commits, tschuett, gbedwell
Differential Revision: https://reviews.llvm.org/D50561
llvm-svn: 339594
|
| |
|
|
| |
llvm-svn: 339468
|
| |
|
|
| |
llvm-svn: 339448
|
| |
|
|
| |
llvm-svn: 339404
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D50381
llvm-svn: 339362
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D49979
llvm-svn: 339358
|
| |
|
|
| |
llvm-svn: 339330
|
| |
|
|
|
|
| |
It previously erroneously said only VS2015 was required.
llvm-svn: 339329
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LLVM triple normalization is handling "unknown" and empty components
differently; for example given "x86_64-unknown-linux-gnu" and
"x86_64-linux-gnu" which should be equivalent, triple normalization
returns "x86_64-unknown-linux-gnu" and "x86_64--linux-gnu". autoconf's
config.sub returns "x86_64-unknown-linux-gnu" for both
"x86_64-linux-gnu" and "x86_64-unknown-linux-gnu". This changes the
triple normalization to behave the same way, replacing empty triple
components with "unknown".
This addresses PR37129.
Differential Revision: https://reviews.llvm.org/D50219
llvm-svn: 339294
|
| |
|
|
|
|
|
| |
Exactly one counted region is inserted into a function record for every
region in a coverage mapping.
llvm-svn: 339193
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
We do need to map /Zi to /Z7 explicitly for msbuild as explained in this file,
but since /Zi is passed by default and since things transparently work fine
with it mapped to /Z7, we shouldn't produce effectively inactionable noise for
it.
Also don't warn on /X since clang-cl supports that (since r326357; the risk of
duplicating a bunch of clang-cl driver logic here).
https://reviews.llvm.org/D50398
llvm-svn: 339169
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Hello!
This commit adds a LLVM-C target that is always built on MSVC. A big fat warning, this is my first cmake code ever so there is a fair bit of I-have-no-idea-what-I'm-doing going on here. Which is also why I placed it outside of llvm-shlib as I was afraid of breaking things of other people. Secondly llvm-shlib builds a LLVM.so which exports all symbols and then does a thin library that points to it, but on Windows we do not build a LLVM.dll so that would have complicated the code more.
The patch includes a python script that calls dumpbin.exe to get all of the symbols from the built libraries. It then grabs all the symbols starting with LLVM and generates the export file from those. The export file is then used to create the library just like the LLVM-C that is built on darwin.
Improvements that I need help with, to follow up this review.
- Get cmake to make sure that dumpbin.exe is on the path and wire the full path to the script.
- Use LLVM-C.dll when building llvm-c-test so we can verify that the symbols are exported.
- Bundle the LLVM-C.dll with the windows installer.
Why do this? I'm building a language frontend which is self-hosting, and on windows because of various tooling issues we have a problem of consuming the LLVM*.lib directly on windows. Me and the users of my projects using LLVM would be greatly helped by having LLVM-C.dll built and shipped by the Windows installer. Not only does LLVM takes forever to build, you have to run a extra python script in order to get the final DLL.
Any comments, thoughts or help is greatly appreciated.
Cheers, Jakob.
Patch by: Wallbraker (Jakob Bornecrantz)
Reviewers: compnerd, beanz, hans, smeenai
Reviewed By: beanz
Subscribers: xbolva00, bhelyer, Memnarch, rnk, fedor.sergeev, chapuni, smeenai, john.brawn, deadalnix, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D35077
llvm-svn: 339151
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The accelerator tables use the debug_str section to store their strings.
However, they do not support the indirect method of access that is
available for the debug_info section (DW_FORM_strx et al.).
Currently our code is assuming that all strings can/will be referenced
indirectly, and puts all of them into the debug_str_offsets section.
This is generally true for regular (unsplit) dwarf, but in the DWO case,
most of the strings in the debug_str section will only be used from the
accelerator tables. Therefore the contents of the debug_str_offsets
section will be largely unused and bloating the main executable.
This patch rectifies this by teaching the DwarfStringPool to
differentiate between strings accessed directly and indirectly. When a
user inserts a string into the pool it has to declare whether that
string will be referenced directly or not. If at least one user requsts
indirect access, that string will be assigned an index ID and put into
debug_str_offsets table. Otherwise, the offset table is skipped.
This approach reduces the overall binary size (when compiled with
-gdwarf-5 -gsplit-dwarf) in my tests by about 2% (debug_str_offsets is
shrunk by 99%).
Reviewers: probinson, dblaikie, JDevlieghere
Subscribers: aprantl, mgrang, llvm-commits
Differential Revision: https://reviews.llvm.org/D49493
llvm-svn: 339122
|
| |
|
|
| |
llvm-svn: 339119
|
| |
|
|
| |
llvm-svn: 339118
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D50335
llvm-svn: 339117
|
| |
|
|
|
|
|
|
|
|
| |
I was trying to add a test case for LLD and found that it
is impossible to set sh_entsize via yaml.
The patch implements the missing part.
Differential revision: https://reviews.llvm.org/D50235
llvm-svn: 339113
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D50258
llvm-svn: 339045
|
| |
|
|
| |
llvm-svn: 338951
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Scheduler.
This patch is a follow-up to r338702.
We don't need to use a map to model the wait/ready/issued sets. It is much more
efficient to use a vector instead.
This patch gives us an average 7.5% speedup (on top of the ~12% speedup obtained
after r338702).
llvm-svn: 338883
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: Functional No Op.
Reviewers: gchatelet
Subscribers: tschuett, courbet, llvm-commits
Differential Revision: https://reviews.llvm.org/D50231
llvm-svn: 338836
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This change removes the ad-hoc implementation used by llvm-xray's
`convert` subcommand to generate JSON encoded catapult (AKA Chrome
Trace Viewer) trace output, to instead use the JSON encoder now in the
Support library.
Reviewers: kpw, zturner, eizan
Reviewed By: kpw
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D50129
llvm-svn: 338834
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
With Mach-O, there is a flag requirement discrepancy between working with
universal binaries and thin binaries. Many flags that don't require the `-macho`
flag (for example `-private-headers` and `-disassemble`) fail to work on
universal binaries unless `-macho` is given. When this happens, the error
message is unhelpful, stating:
The file was not recognized as a valid object file.
Which can lead to confusion.
This change allows generic flags to be used on universal binaries with and
without the `-macho` flag. This means flags that can be used for thin files can
be used consistently with fat files too.
To do this, the universal binary support within `ParseInputMachO()` is extracted
into a new function. This new function is called directly from `DumpInput()`
when the input binary is universal. Additionally the `-arch` flag validation in
`ParseInputMachO()` was extracted to be reused.
Reviewers: compnerd
Reviewed By: compnerd
Subscribers: keith, llvm-commits
Differential Revision: https://reviews.llvm.org/D48702
llvm-svn: 338792
|
| |
|
|
| |
llvm-svn: 338759
|
| |
|
|
| |
llvm-svn: 338752
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This option is no longer needed since r300496 added symbol
versioning by default
Reviewers: sylvestre.ledru, beanz, mgorny
Reviewed By: mgorny
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D49835
llvm-svn: 338751
|
| |
|
|
| |
llvm-svn: 338740
|
| |
|
|
|
|
|
|
|
|
|
| |
Corrected and simplified the help text.
It was clearly too difficult to maintain before (see e.g. @227296) making it
simpler and more consistent it should help people keep it up to date.
Differential Revision: https://reviews.llvm.org/D48577
llvm-svn: 338703
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We don't need to use a map to store ResourceState objects. The number of
processor resources is known statically from the scheduling model. We can
therefore use a vector, and reserve a slot for each processor resource that we
want to simulate.
Every time the ResourceManager queries the ResourceState vector, the index to
the vector of ResourceState objects can be easily computed from the processor
resource mask.
This drastically reduces the time complexity of method ResourceManager::use() and
method ResourceManager::release(). This patch gives an average speedup of 12%.
llvm-svn: 338702
|
| |
|
|
|
|
|
|
|
|
| |
Summary: Non functional change.
Subscribers: tschuett, courbet, llvm-commits
Differential Revision: https://reviews.llvm.org/D50176
llvm-svn: 338701
|
| |
|
|
| |
llvm-svn: 338635
|
| |
|
|
|
|
|
|
|
| |
This is useful for understanding how our demangler processes
back references and for investigating issues related to
back references. But it's a feature only useful for debugging
the demangling process itself, so I'm marking it hidden.
llvm-svn: 338609
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Add support for --rename-section flags from gnu objcopy.
Not all flags appear to have an effect for ELF objects, but allowing them would allow easier drop-in replacement. Other unrecognized flags are rejected.
This was only tested by comparing flags printed by "readelf -e <.o>" against the output of gnu vs llvm objcopy, it hasn't been tested to be valid beyond that.
Reviewers: jakehehrlich, alexshap
Subscribers: llvm-commits, paulsemel, alexshap
Differential Revision: https://reviews.llvm.org/D49870
llvm-svn: 338582
|
| |
|
|
|
|
| |
Found by inspection.
llvm-svn: 338579
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
And implement memory instructions on X86.
This fixes PR36906.
Reviewers: gchatelet
Reviewed By: gchatelet
Subscribers: lebedev.ri, filcab, mgorny, tschuett, RKSimon, llvm-commits
Differential Revision: https://reviews.llvm.org/D48935
llvm-svn: 338567
|