This is necessary to pass the lit test suite at llvm/utils/lit/tests.
There are some pre-existing failures here, but now switching to pools
doesn't regress any tests.
I had to change test-data/lit.cfg to import DummyConfig from a module to
fix pickling problems, but I think it'll be OK if we require test
formats to be written in real .py modules outside lit.cfg files.
I also discovered that in some circumstances AsyncResult.wait() will not
raise KeyboardInterrupt in a timely manner, but you can pass a non-zero
timeout to work around this. This makes threading.Condition.wait use a
polling loop that runs through the interpreter, so it's capable of
asynchronously raising KeyboardInterrupt.
llvm-svn: 299605
- Replace documented return values (true/false) with what's actually
returned
- Doxygenify the comment
- Reflow said comment to 80 cols
Not overly familiar with Doxygen, so nits are welcome. :)
llvm-svn: 299603
Two simplifications:
- We check `!Previous.empty()` above and only use `Previous` in const
contexts after that check, so the `!Previous.empty()` check seems
redundant.
- The null check looks pointless, as well: AFAICT, `LookupResults`
should never contain null entries, and `OldDecl` should always be
non-null if `Redeclaration` is true.
llvm-svn: 299601
When compiler-rt is requested, we should attempt to link compiler-rt
builtins library rather than gcc_s.
Differential Revision: https://reviews.llvm.org/D31617
llvm-svn: 299599
The commit yesterday (r299473) to add the `-print-resource-dir`
option was supposed to emit a newline after the resource dir.
Differential Revision: https://reviews.llvm.org/D31447
llvm-svn: 299597
Moving Modules into `testMergedProgram` is incorrect (and causes segmentation
faults) since all callers expect to retain ownership. This is evidenced by the
later calls to `unique_ptr<Module>::get` in the same function.
Differential Revision: https://reviews.llvm.org/D31727
llvm-svn: 299596
Summary:
LSV wants to know the maximum size that can be loaded to a vector register.
On X86, this always matches the maximum register width. Implement this
accordingly and add a test to make sure that LSV can vectorize up to the
maximum permissible width on X86.
Reviewers: delena, arsenm
Reviewed By: arsenm
Subscribers: wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D31504
llvm-svn: 299589
I have put them all in their own category, and made that category disabled by default.
Differential revision: https://reviews.llvm.org/D31718
llvm-svn: 299587
There are two cases to consider:
We are using the internal shell. This will still fail because of
ulimit.
We are using an external shell. In this case the difference is that we
now also constrain FileCheck to use less than 4 MB of of stack, which
it should :-)
llvm-svn: 299586
The current StackColoring algorithm does not correctly handle the
situation when some, but not all paths from a BB to the entry node
cross a llvm.lifetime.start. According to an interpretation of the
language reference at
http://llvm.org/docs/LangRef.html#llvm-lifetime-start-intrinsic
this might be correct, but it would cost too much effort to handle
in StackColoring.
To be on the safe side, remove all lifetime markers even in the original
code version (they have never been copied to the optimized version)
to ensure that no path to the entry block will cross a
llvm.lifetime.start.
The same principle applies to paths the a function return and the
llvm.lifetime.end marker, so we remove them as well.
This fixes llvm.org/PR32251.
Also see the discussion at
http://lists.llvm.org/pipermail/llvm-dev/2017-March/111551.html
llvm-svn: 299585
Summary:
Remove all the caching the clobber walker does, and that the
caching walker does. With the patch to enable storing clobbering
access results for stores, i can find no improvement with the cache
turned on (and a number of degradations, both time and memory, from
the cost of caching. For a large program i have, we do millions of
lookups and inserts with zero hits).
I haven't tried to rename or simplify the walker otherwise yet.
(Appreciate some perf testing on this past my own testing)
Reviewers: george.burgess.iv, davide
Subscribers: Prazek, llvm-commits
Differential Revision: https://reviews.llvm.org/D31576
llvm-svn: 299578
Move the test format into a standalone .py file and add it to the site
module search path. This allows us to run the test on Windows, and it
makes it compatible with the multiprocessing.Pool lit test execution
strategy.
I think this test was only passing everywhere else because
multiprocessing uses 'fork' to spawn workers, so the test format never
needs to be pickled.
llvm-svn: 299577
Note payloads are padded to a multiple of 4 bytes in size, but the size
of the string that should be print can be smaller e.g. the n_descsz
field in gold's version note is 9, so that's the whole size of the
string that should be printed. The padding is part of the format of a
SHT_NOTE section or PT_NOTE segment, but it's not part of the note
itself.
Printing the extra null bytes may confuse some tools, e.g. when the
llvm-readobj is sent to grep, it treats the output as binary because
it contains a null byte.
Differential Revision: https://reviews.llvm.org/D30804
llvm-svn: 299576
On certain versions of android x86, the main module `app_process` is not
built as PIE. When accessing the PT_GNU_EH_FRAME_HDR in such a
scenario, the `dlpi_addr` is 0, but the virtual address is not
relocated. Manually rebase the address to avoid an invalid memory
access.
llvm-svn: 299575
clang-format <<END
auto c1 = u8'a';
auto c2 = u'a';
END
Before:
auto c1 = u8 'a';
auto c2 = u'a';
Now:
auto c1 = u8'a';
auto c2 = u'a';
Patch from Denis Gladkikh <llvm@denis.gladkikh.email>!
llvm-svn: 299574
Symbols referenced by linker scripts are not necessarily be undefined,
so the previous name didn't convey the meaining of the variable.
llvm-svn: 299573
This is a follow-on to r299096 which added support for fmadd.
Subtract does not have the case where with two multiply operands we commute in
order to fuse with the multiply with the fewer uses.
llvm-svn: 299572
Summary:
Use an explicit work queue instead, to avoid accidentally
causing stack overflows for input with very large CFGs.
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D31681
llvm-svn: 299569
There must be some opportunity to refactor big chunks of nearly duplicated code in FoldOrOfICmps / FoldAndOfICmps.
Also, none of this works with vectors, but it should.
llvm-svn: 299568
Summary:
This drastically reduces lit test execution startup time on Windows. Our
previous strategy was to manually create one Process per job and manage
the worker pool ourselves. Instead, let's use the worker pool provided
by multiprocessing. multiprocessing.Pool(jobs) returns almost
immediately, and initializes the appropriate number of workers, so they
can all start executing tests immediately. This avoids the ramp-up
period that the old implementation suffers from. This appears to speed
up small test runs.
Here are some timings of the llvm-readobj tests on Windows using the
various execution strategies:
# multiprocessing.Pool:
$ for i in `seq 1 3`; do tim python ./bin/llvm-lit.py -sv ../llvm/test/tools/llvm-readobj/ --use-process-pool |& grep real: ; done
real: 0m1.156s
real: 0m1.078s
real: 0m1.094s
# multiprocessing.Process:
$ for i in `seq 1 3`; do tim python ./bin/llvm-lit.py -sv ../llvm/test/tools/llvm-readobj/ --use-processes |& grep real: ; done
real: 0m6.062s
real: 0m5.860s
real: 0m5.984s
# threading.Thread:
$ for i in `seq 1 3`; do tim python ./bin/llvm-lit.py -sv ../llvm/test/tools/llvm-readobj/ --use-threads |& grep real: ; done
real: 0m9.438s
real: 0m10.765s
real: 0m11.079s
I kept the old code to launch processes in case this change doesn't work
on all platforms that LLVM supports, but at some point I would like to
remove both the threading and old multiprocessing execution strategies.
Reviewers: modocache, rafael
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31677
llvm-svn: 299560
Commit r298799 changed code that made the XFAIL on MachineBranchProb.ll
irrelevant, but some configurations still failed. I can't reproduce it
locally, so I'm hoping that enabling this will tell me if some
configurations will really fail or if they were just too slow.
llvm-svn: 299558
Mehdi Amini