Added some commonly used Arm triples to the script, with and without
the -eabi suffix.
Differential Revision: https://reviews.llvm.org/D40708
llvm-svn: 319545
Summary:
1/ Operand folding during complex pattern matching for LEAs has been extended, such that it promotes Scale to
accommodate similar operand appearing in the DAG e.g.
T1 = A + B
T2 = T1 + 10
T3 = T2 + A
For above DAG rooted at T3, X86AddressMode will now look like
Base = B , Index = A , Scale = 2 , Disp = 10
2/ During OptimizeLEAPass down the pipeline factorization is now performed over LEAs so that if there is an opportunity
then complex LEAs (having 3 operands) could be factored out e.g.
leal 1(%rax,%rcx,1), %rdx
leal 1(%rax,%rcx,2), %rcx
will be factored as following
leal 1(%rax,%rcx,1), %rdx
leal (%rdx,%rcx) , %edx
3/ Aggressive operand folding for AM based selection for LEAs is sensitive to loops, thus avoiding creation of any complex LEAs within a loop.
4/ Simplify LEA converts (lea (BASE,1,INDEX,0) --> add (BASE, INDEX) which offers better through put.
PR32755 will be taken care of by this pathc.
Previous patch revisions : r313343 , r314886
Reviewers: lsaba, RKSimon, craig.topper, qcolombet, jmolloy, jbhateja
Reviewed By: lsaba, RKSimon, jbhateja
Subscribers: jmolloy, spatel, igorb, llvm-commits
Differential Revision: https://reviews.llvm.org/D35014
llvm-svn: 319543
When we break a long line like:
Column limit: 21
|
// foo foo foo foo foo foo foo foo foo foo foo foo
The local decision when to allow protruding vs. breaking can lead to this
outcome (2 excess characters, 2 breaks):
// foo foo foo foo foo
// foo foo foo foo foo
// foo foo
While strictly staying within the column limit leads to this strictly better
outcome (fully below the column limit, 2 breaks):
// foo foo foo foo
// foo foo foo foo
// foo foo foo foo
To get an optimal solution, we would need to consider all combinations of excess
characters vs. breaking for all lines, but that would lead to a significant
increase in the search space of the algorithm for little gain.
Instead, we blindly try both approches and·select the one that leads to the
overall lower penalty.
Differential Revision: https://reviews.llvm.org/D40605
llvm-svn: 319541
Summary:
A true or false result is expected from a comparison, but it seems the possibility of undef was overlooked, which could lead to a failed assert. This is fixed by this patch by bailing out if we encounter undef.
The bug is old and the assert has been there since the end of 2014, so it seems this is unusual enough to forego optimization.
Patch by: JesperAntonsson
Reviewers: spatel, eeckstein, hans
Reviewed By: hans
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D40639
llvm-svn: 319537
struct iovec is used as an interface to system (posix) api's. As such,
we shouldn't be using it in os-independent code, and we shouldn't be
defining our own iovec replacements.
Fortunately, its usage was not very widespread, so the removal was very
easy -- I simply moved a couple declarations into os-specific code.
llvm-svn: 319536
Summary:
zlib support was hard-wired to off for (non-cygwin) windows targets.
This disables some features, such as reading debug info from compressed
dwarf sections.
This has been this way since zlib support was added in 2013 (r180083),
but there is no obvious reason for that. Zlib is perfectly capable of
being compiled for windows (it even has a cmake file that works out of
the box).
This enables one to turn on zlib support on windows, if one has zlib
avaliable.
Reviewers: rnk, beanz
Subscribers: mgorny, aprantl, llvm-commits
Differential Revision: https://reviews.llvm.org/D40655
llvm-svn: 319533
Patch tries to improve vectorization of the following code:
void add1(int * __restrict dst, const int * __restrict src) {
*dst++ = *src++;
*dst++ = *src++ + 1;
*dst++ = *src++ + 2;
*dst++ = *src++ + 3;
}
Allows to vectorize even if the very first operation is not a binary add, but just a load.
Fixed issues related to previous commit.
Reviewers: spatel, mzolotukhin, mkuper, hfinkel, RKSimon, filcab, ABataev
Reviewed By: ABataev, RKSimon
Subscribers: llvm-commits, RKSimon
Differential Revision: https://reviews.llvm.org/D28907
llvm-svn: 319531
The latest clang that ships with Xcode (clang 900 or 9.0.0) does not
support LSan. This fixes the lit configuration to reflect that.
Differential revision: https://reviews.llvm.org/D40672
llvm-svn: 319530
This reverts commit r319525.
This change has introduced a problem with the Lit tests build for compiler-rt using Gold: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/6047/steps/test%20standalone%20compiler-rt/logs/stdio
llvm-lit: /b/sanitizer-x86_64-linux/build/llvm/utils/lit/lit/TestingConfig.py:101: fatal: unable to parse config file '/b/sanitizer-x86_64-linux/build/llvm/projects/compiler-rt/test/profile/Linux/lit.local.cfg', traceback: Traceback (most recent call last):
File "/b/sanitizer-x86_64-linux/build/llvm/utils/lit/lit/TestingConfig.py", line 88, in load_from_path
exec(compile(data, path, 'exec'), cfg_globals, None)
File "/b/sanitizer-x86_64-linux/build/llvm/projects/compiler-rt/test/profile/Linux/lit.local.cfg", line 37, in <module>
if root.host_os not in ['Linux'] or not is_gold_linker_available():
File "/b/sanitizer-x86_64-linux/build/llvm/projects/compiler-rt/test/profile/Linux/lit.local.cfg", line 27, in is_gold_linker_available
stderr = subprocess.PIPE)
File "/usr/lib/python2.7/subprocess.py", line 390, in __init__
errread, errwrite)
File "/usr/lib/python2.7/subprocess.py", line 1024, in _execute_child
raise child_exception
OSError: [Errno 2] No such file or directory
llvm-svn: 319529
This is for "Bug 35474 - --emit-relocs produces wrongly-named reloc sections".
LLD currently for scripts like:
.text.boot : { *(.text.boot) }
emits relocation section with name .rela.text because does not take
redefined name of output section into account and builds section name
using rules for non-scripted case. Patch fixes this oddness.
Differential revision: https://reviews.llvm.org/D40652
llvm-svn: 319526
Summary:
As discussed in https://github.com/google/oss-fuzz/issues/933,
it would be really awesome to be able to use ThinLTO for fuzzing.
However, as @kcc has pointed out, it is currently undefined (untested)
whether the sanitizers actually function properly with LLD and/or LTO.
This patch is inspired by the cfi test, which already do test with LTO
(and/or LLD), since LTO is required for CFI to function.
I started with UBSan, because it's cmakelists / lit.* files appeared
to be the cleanest. This patch adds the infrastructure to easily add
LLD and/or LTO sub-variants of the existing lit test configurations.
Also, this patch adds the LLD flavor, that explicitly does use LLD to link.
The check-ubsan does pass on my machine. And to minimize the [initial]
potential buildbot breakage i have put some restrictions on this flavour.
Please review carefully, i have not worked with lit/sanitizer tests before.
Reviewers: eugenis, vitalybuka
Reviewed By: eugenis
Subscribers: #sanitizers, pcc, kubamracek, mgorny, llvm-commits, mehdi_amini, inglorion, kcc
Differential Revision: https://reviews.llvm.org/D39508
llvm-svn: 319525
Summary: LegalizerInfo assumes all G_MERGE_VALUES and G_UNMERGE_VALUES instructions are legal, so it is not possible to legalize vector operations on illegal vector types. This patch fixes the problem by removing the related check and adding default actions for G_MERGE_VALUES and G_UNMERGE_VALUES.
Reviewers: qcolombet, ab, dsanders, aditya_nandakumar, t.p.northover, kristof.beyls
Reviewed By: dsanders
Subscribers: rovka, javed.absar, igorb, llvm-commits
Differential Revision: https://reviews.llvm.org/D39823
llvm-svn: 319524
Use this source use on Fuchsia where this is the oficially way
to obtain randomness. This could be also used on other platforms
that already support getentropy such as *BSD or Linux.
Differential Revision: https://reviews.llvm.org/D40319
llvm-svn: 319523
The default legalization for v2i32 is promotion to v2i64. This results in a gather that reads 64-bit elements rather than 32. If one of the elements is near a page boundary this can cause an illegal access that can fault.
We also miscalculate the scale for the gather which is an even worse problem, but we probably could have found a separate way to fix that.
llvm-svn: 319521
Type promotion makes no guarantee about the contents of the promoted bits. Since the gather/scatter instruction will use the bits to calculate addresses, we need to ensure they aren't garbage.
llvm-svn: 319520
AddLLVM is needed for several functions that are used in tests and
as such needs to be included from the right context which previously
wasn't the case.
Differential Revision: https://reviews.llvm.org/D40280
llvm-svn: 319515
Summary:
Support was added in rL319488 but these tests were not
updated.
Subscribers: jfb, dschuff, jgravelle-google, aheejin, sunfish
Differential Revision: https://reviews.llvm.org/D40693
llvm-svn: 319510
Even with the sparse file optimizations the SYM64 test can still be painfully
slow. This unnecessarily slows down devs. It's critical that we test that the
switch to the SYM64 format occurs at 4GB but there isn't any better of a way to
fake the size of the file than sparse files. This change introduces a flag that
allows the cutoff to be arbitrarily set to whatever power of two is desired.
The flag is hidden as it really isn't meant to be used outside this one test.
This is unfortunate but appears necessary, at least until the average hard
drive is much faster.
The changes to the test require some explanation. Prior to this change we knew
that the SYM64 format was being used because the file was simply too large to
have validly handled this case if the SYM64 format were not used. To ensure
that the SYM64 format is still being used I am grepping the file for "SYM64".
Without changing the filename however this would be pointless because "SYM64"
would occur in the file either way. So the filename of the test is also changed
in order to avoid this issue.
Differential Revision: https://reviews.llvm.org/D40632
llvm-svn: 319507
These command line options are not intended for public use, and often
don't even make sense in the context of a particular tool anyway. About
90% of them are already hidden, but when people add new options they
forget to hide them, so if you were to make a brand new tool today, link
against one of LLVM's libraries, and run tool -help you would get a
bunch of junk that doesn't make sense for the tool you're writing.
This patch hides these options. The real solution is to not have
libraries defining command line options, but that's a much larger effort
and not something I'm prepared to take on.
Differential Revision: https://reviews.llvm.org/D40674
llvm-svn: 319505
This is basically a proof-of-concept and starting point for having a
testing-centric tool in LLDB. I'm sure this leaves a lot of room to be
desired, but this at least allows us to have something to build on.
Right now there is only one command, the `module-sections` command, and I
created this command not because it was particularly special, but
because it addressed an immediate use case and was extremely simple.
Run the tool as `lldb-test module-sections <path-to-object>`.
Feel free to add testing related stuff to your heart's content after
this goes in. Implementing the commands themselves takes some work, but
once they're there they can be reused without writing any code and
result in very easy to use and maintain tests.
Differential Revision: https://reviews.llvm.org/D40636
llvm-svn: 319504
but still listed in the kernel's kext table with the kernel
binary UUID. This resulted in the kernel text section being
loaded at the kext address and problems ensuing. Instead,
if there is a kext with the same UUID as the kernel, lldb
should skip over it.
<rdar://problem/35757689>
llvm-svn: 319500
LLVM is gaining install-*-stripped targets to perform stripped installs,
and in order for this to be useful for install-distribution, all
potential distribution components should have stripped installation
targets. LLVM has a function to create these install targets, but since
we can't use LLVM CMake functions in libc++abi, let's do it manually.
Differential Revision: https://reviews.llvm.org/D40681
llvm-svn: 319499
