| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
Replacing range loops.
Reviewed by: @MatzeB
Differential Revision: https://reviews.llvm.org/D38091
llvm-svn: 313874
|
|
|
|
| |
llvm-svn: 313860
|
|
|
|
|
|
| |
structure we use.
llvm-svn: 313859
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This appears to break some bots, when getToolsPath fails to find some or
all of the tools (for example, an incomplete GnuWin32 installation).
Reviewers: zturner, modocache
Subscribers: sanjoy, llvm-commits
Differential Revision: https://reviews.llvm.org/D38115
llvm-svn: 313854
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Many editors and Python-related diagnostics tools such as
debuggers break or fail in mysterious ways when python files
don't end in .py. This is especially true on Windows, but
still exists on other platforms. I don't want to be too heavy
handed in changing everything across the board, but I do want
to at least *allow* lit configs to have .py extensions. This
patch makes the discovery process first look for a config file
with a .py extension, and if one is not found, then looks for
a config file using the old method. So for existing users, there
should be no functional change.
Differential Revision: https://reviews.llvm.org/D37838
llvm-svn: 313849
|
|
|
|
|
|
|
| |
The problems on the bots appear to be resolved and this was
determined to not be the culprit. Removing this.
llvm-svn: 313807
|
|
|
|
|
|
|
|
|
| |
This changes some STL data types to corresponding LLVM
data types that have better performance characteristics.
Differential Revision: https://reviews.llvm.org/D37957
llvm-svn: 313783
|
|
|
|
|
|
|
|
| |
Bug pointed out by EricWF. This would construct a path where
items would be added in the wrong order, potentially leading
to using the wrong tools for testing.
llvm-svn: 313765
|
|
|
|
|
|
|
|
|
|
|
|
| |
Many svn-based buildbots seem to be getting stuck continually
in tree conflicts due to the output of pyc files. I'm disabling
these as a temporary measure in an attempt to get everything
stable again.
I'll try to remove this code once I understand the problem
better.
llvm-svn: 313698
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
formatted_raw_ostream.
The generated DAG isel file currently makes use of formatted_raw_ostream primarily for generating a hierarchical representation while also skipping over the initial comment that contains the current index.
It was reported in D37957 that this formatting might be slow due to the need to keep track of column numbers by monitoring all the written data for new lines.
This patch attempts to rewrite the emitter to make use of simpler formatting mechanisms to generate a fairly similar output. The main difference is that the number in the index comment is now right justified and padded with spaces inside the comment. Previously we appended the spaces after the comment.
Differential Revision: https://reviews.llvm.org/D37966
llvm-svn: 313674
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add some member types to MachineValueTypeSet::const_iterator so that
iterator_traits can work with it.
Improve TableGen performance of -gen-dag-isel (motivated by X86 backend)
The introduction of parameterized register classes in r313271 caused the
matcher generation code in TableGen to run much slower, particularly so
in the unoptimized (debug) build. This patch recovers some of the lost
performance.
Summary of changes:
- Cache the set of legal types in TypeInfer::getLegalTypes. The contents
of this set do not change.
- Add LLVM_ATTRIBUTE_ALWAYS_INLINE to several small functions. Normally
this would not be necessary, but in the debug build TableGen is not
optimized, so this helps a little bit.
- Add an early exit from TypeSetByHwMode::operator== for the case when
one or both arguments are "simple", i.e. only have one mode. This
saves some time in GenerateVariants.
- Finally, replace the underlying storage type in TypeSetByHwMode::SetType
with MachineValueTypeSet based on std::array instead of std::set.
This significantly reduces the number of memory allocation calls.
I've done a number of experiments with the underlying type of InfoByHwMode.
The type is a map, and for targets that do not use the parameterization,
this map has only one entry. The best (unoptimized) performance, somewhat
surprisingly came from std::map, followed closely by std::unordered_map.
DenseMap was the slowest by a large margin.
Various hand-crafted solutions (emulating enough of the map interface
not to make sweeping changes to the users) did not yield any observable
improvements.
llvm-svn: 313660
|
|
|
|
|
|
|
|
| |
backend)"
It breaks a lot of bots due to missing "__iterator_category".
llvm-svn: 313651
|
|
|
|
| |
llvm-svn: 313649
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The introduction of parameterized register classes in r313271 caused the
matcher generation code in TableGen to run much slower, particularly so
in the unoptimized (debug) build. This patch recovers some of the lost
performance.
Summary of changes:
- Cache the set of legal types in TypeInfer::getLegalTypes. The contents
of this set do not change.
- Add LLVM_ATTRIBUTE_ALWAYS_INLINE to several small functions. Normally
this would not be necessary, but in the debug build TableGen is not
optimized, so this helps a little bit.
- Add an early exit from TypeSetByHwMode::operator== for the case when
one or both arguments are "simple", i.e. only have one mode. This
saves some time in GenerateVariants.
- Finally, replace the underlying storage type in TypeSetByHwMode::SetType
with MachineValueTypeSet based on std::array instead of std::set.
This significantly reduces the number of memory allocation calls.
I've done a number of experiments with the underlying type of InfoByHwMode.
The type is a map, and for targets that do not use the parameterization,
this map has only one entry. The best (unoptimized) performance, somewhat
surprisingly came from std::map, followed closely by std::unordered_map.
DenseMap was the slowest by a large margin.
Various hand-crafted solutions (emulating enough of the map interface
not to make sweeping changes to the users) did not yield any observable
improvements.
llvm-svn: 313647
|
|
|
|
|
|
| |
This maps directly to G_INTRINSIC_W_SIDE_EFFECTS.
llvm-svn: 313627
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since the path a user specifies to the llvm-lit script might be
different than the source tree they built from (since they could
be behind different symlinks), we need to use realpath to make
sure that path comparisons work as expected.
Even better would be to use a custom dictionary comparison with
actual file equivalence comparison semantics, but this is the
least friction to unbreak things for now.
llvm-svn: 313594
|
|
|
|
|
|
|
| |
I was using the pattern as the source string and vice versa
causing strange regular expression errors.
llvm-svn: 313590
|
|
|
|
| |
llvm-svn: 313580
|
|
|
|
|
|
|
| |
NFC intended here, this only updates clang and lld's lit configs
to use some helper functionality in the lit.llvm submodule.
llvm-svn: 313579
|
|
|
|
|
|
|
| |
Lambdas are slightly more verbose, but also more readable. No
functionality change intended.
llvm-svn: 313482
|
|
|
|
|
|
|
|
|
| |
It doesn't make sense to me why these bots are failing as the
traceback does not agree with the source code. It's possible
something is stale or there is some other mysterious error,
but in any case hopefully this fixes it.
llvm-svn: 313469
|
|
|
|
|
|
|
|
| |
There were some issues surrounding Py2 / Py3 compatibility, but
I've now tested with both Py2 and Py3 and everything seems to
work.
llvm-svn: 313467
|
|
|
|
| |
llvm-svn: 313466
|
|
|
|
|
|
|
|
| |
A few tests were manually constructing a LitConfig object, since
I added a new argument to it this was triggering some failures
I didn't detect. `ninja check-lit` passes now.
llvm-svn: 313461
|
|
|
|
|
|
|
|
|
| |
This is helpful for debugging test failures since it removes
the multiprocessing pool from the picture. This will obviously
slow down the test suite by a few orders of magnitude, so it
should only be used for debugging specific failures.
llvm-svn: 313460
|
|
|
|
|
|
| |
latest Python versions.
llvm-svn: 313435
|
|
|
|
|
|
|
|
| |
It looks like this is going to be non-trivial to get working
in both Py2 and Py3, so for now I'm reverting until I have time
to fully test it under Python 3.
llvm-svn: 313429
|
|
|
|
|
|
|
| |
Apparently we have a buildbot running Python 3. This is going
to be fun :-/
llvm-svn: 313428
|
|
|
|
|
|
|
| |
Some versions of python don't have 'long'. Use numbers.Number
instead.
llvm-svn: 313427
|
|
|
|
|
|
|
| |
This was reverted alongside the revert of the lit/llvm-lit refactor,
but now that that has re-landed, I'm relanding this as well.
llvm-svn: 313426
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a resubmission of r313270. It broke standalone builds of
compiler-rt because we were not correctly generating the llvm-lit
script in the standalone build directory.
The fixes incorporated here attempt to find llvm/utils/llvm-lit
from the source tree returned by llvm-config. If present, it
will generate llvm-lit into the output directory. Regardless,
the user can specify -DLLVM_EXTERNAL_LIT to point to a specific
lit.py on their file system. This supports the use case of
someone installing lit via a package manager. If it cannot find
a source tree, and -DLLVM_EXTERNAL_LIT is either unspecified or
invalid, then we print a warning that tests will not be able
to run.
Differential Revision: https://reviews.llvm.org/D37756
llvm-svn: 313407
|
|
|
|
|
|
| |
Collect all legal types for all modes.
llvm-svn: 313380
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This commit also adds a script to compute sha256 hashes of llvm checkouts.
Reviewers: klimek, mehdi_amini
Reviewed By: klimek
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D37099
llvm-svn: 313359
|
|
|
|
|
|
|
|
| |
This patch is still breaking several multi-stage compiler-rt bots.
I already know what the fix is, but I want to get the bots green
for now and then try re-applying in the morning.
llvm-svn: 313335
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This will be used instead of the url field to track which commits need
to be merged.
This patch also drops support for version 1.x of the bugzilla CLI tool.
Reviewers: hansw, hans
Reviewed By: hans
Subscribers: hans, llvm-commits
Differential Revision: https://reviews.llvm.org/D37786
llvm-svn: 313334
|
|
|
|
|
|
|
| |
This is breaking due to some changes I forgot to merge in, so I'm
temporarily reverting them until I can re-test that this works.
llvm-svn: 313328
|
|
|
|
| |
llvm-svn: 313326
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To further reduce duplicate code, this patch introduces a module
that configs can simply import and get access to a lot of useful
functionality such as setting up paths, adding features that are
useful across all projects, and other utility-type functions.
For now this only updates llvm's suite to use this new library,
but subsequent patches will update other projects.
Differential Revision: https://reviews.llvm.org/D37778
llvm-svn: 313325
|
|
|
|
| |
llvm-svn: 313301
|
|
|
|
|
|
|
|
| |
Implement "checkFeatures" and emitting HW mode check code.
Differential Revision: https://reviews.llvm.org/D31959
llvm-svn: 313295
|
|
|
|
|
|
|
|
|
|
| |
These are removed in C++17. We still have some users of
unary_function::argument_type, so just spell that typedef out. No
functionality change intended.
Note that many of the argument types are actually wrong :)
llvm-svn: 313287
|
|
|
|
| |
llvm-svn: 313273
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This replaces TableGen's type inference to operate on parameterized
types instead of MVTs, and as a consequence, some interfaces have
changed:
- Uses of MVTs are replaced by ValueTypeByHwMode.
- EEVT::TypeSet is replaced by TypeSetByHwMode.
This affects the way that types and type sets are printed, and the
tests relying on that have been updated.
There are certain users of the inferred types outside of TableGen
itself, namely FastISel and GlobalISel. For those users, the way
that the types are accessed have changed. For typical scenarios,
these replacements can be used:
- TreePatternNode::getType(ResNo) -> getSimpleType(ResNo)
- TreePatternNode::hasTypeSet(ResNo) -> hasConcreteType(ResNo)
- TypeSet::isConcrete -> TypeSetByHwMode::isValueTypeByHwMode(false)
For more information, please refer to the review page.
Differential Revision: https://reviews.llvm.org/D31951
llvm-svn: 313271
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch simplifies LLVM's lit infrastructure by enforcing an ordering
that a site config is always run before a source-tree config.
A significant amount of the complexity from lit config files arises from
the fact that inside of a source-tree config file, we don't yet know if
the site config has been run. However it is *always* required to run
a site config first, because it passes various variables down through
CMake that the main config depends on. As a result, every config
file has to do a bunch of magic to try to reverse-engineer the location
of the site config file if they detect (heuristically) that the site
config file has not yet been run.
This patch solves the problem by emitting a mapping from source tree
config file to binary tree site config file in llvm-lit.py. Then, during
discovery when we find a config file, we check to see if we have a
target mapping for it, and if so we use that instead.
This mechanism is generic enough that it does not affect external users
of lit. They will just not have a config mapping defined, and everything
will work as normal.
On the other hand, for us it allows us to make many simplifications:
* We are guaranteed that a site config will be executed first
* Inside of a main config, we no longer have to assume that attributes
might not be present and use getattr everywhere.
* We no longer have to pass parameters such as --param llvm_site_config=<path>
on the command line.
* It is future-proof, meaning you don't have to edit llvm-lit.in to add
support for new projects.
* All of the duplicated logic of trying various fallback mechanisms of
finding a site config from the main config are now gone.
One potentially noteworthy thing that was required to implement this
change is that whereas the ninja check targets previously used the first
method to spawn lit, they now use the second. In particular, you can no
longer run lit.py against the source tree while specifying the various
`foo_site_config=<path>` parameters. Instead, you need to run
llvm-lit.py.
Differential Revision: https://reviews.llvm.org/D37756
llvm-svn: 313270
|
|
|
|
|
|
| |
No functionality change intended.
llvm-svn: 313269
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Change the type of the Redirects parameter of llvm::sys::ExecuteAndWait,
ExecuteNoWait and other APIs that wrap them from `const StringRef **` to
`ArrayRef<Optional<StringRef>>`, which is safer and simplifies the use of these
APIs (no more local StringRef variables just to get a pointer to).
Corresponding clang changes will be posted as a separate patch.
Reviewers: bkramer
Reviewed By: bkramer
Subscribers: vsk, llvm-commits
Differential Revision: https://reviews.llvm.org/D37563
llvm-svn: 313155
|
|
|
|
|
|
|
|
|
| |
Replacing with range-based loop and substituting 'using'.
Reviewed by: @MatzeB
Differential Revision: https://reviews.llvm.org/D37748
llvm-svn: 313140
|
|
|
|
|
|
| |
These pieces were commented out in r98534 and r129691, i.e. 6+ years ago.
llvm-svn: 313038
|
|
|
|
| |
llvm-svn: 313037
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Since asan is linked dynamically on Darwin, the weak interface symbol
is removed by -Wl,-dead_strip.
Reviewers: kcc, compnerd, aaron.ballman
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D37636
llvm-svn: 312914
|