Differential Revision: https://reviews.llvm.org/D55351

llvm-svn: 348531

llvm-svn: 348530

Summary:
When providing a non-const-callable comparator in a map or set, the
warning diagnostic does not include the point of instantiation of
the container that triggered the warning, which makes it difficult
to track down the problem. This commit improves the diagnostic by
placing it directly in the body of the associative container.

The same change is applied to unordered associative containers, which
had a similar problem.

Finally, this commit cleans up the forward declarations of several
map and unordered_map helpers, which are not needed anymore.

<rdar://problem/41370747>

Reviewers: EricWF, mclow.lists

Subscribers: christof, dexonsmith, llvm-commits

Differential Revision: https://reviews.llvm.org/D48955

llvm-svn: 348529

Summary:
This parses entries in pecoff import tables for imported DLLs and
is intended as the first step to allow LLDB to load a PE's shared
modules when creating a target on the LLDB console. 


Reviewers: rnk, zturner, aleksandr.urakov, lldb-commits, labath, asmith

Reviewed By: labath, asmith

Subscribers: labath, lemo, clayborg, Hui, mgorny, mgrang, teemperor

Differential Revision: https://reviews.llvm.org/D53094

llvm-svn: 348527

Summary:
Windows lldb debugging currently uses a process plugin to handle
launching and attaching to a process. Launching a process via a debug
server (e.g. ds2) and attaching to it with `gdb-remote port` currently
doesn't communicate address information of the executable properly.

Implement DynamicLoaderWindowsDYLD::DidAttach which allow us to
obtain the proper executable load address.

Differential Revision: https://reviews.llvm.org/D55383

llvm-svn: 348526

Otherwise, some tests would fail when a relative path was passed,
because they'd use the relative path from a different directory
than the current working directory.

llvm-svn: 348525

Include CompilerRTCompile in fuzzer tests explicitly.  Otherwise, when
building only libFuzzer, CMake fails due to:

CMake Error at cmake/Modules/AddCompilerRT.cmake:395 (sanitizer_test_compile):
  Unknown CMake command "sanitizer_test_compile".
Call Stack (most recent call first):
  lib/fuzzer/tests/CMakeLists.txt:53 (generate_compiler_rt_tests)

Differential Revision: https://reviews.llvm.org/D55378

llvm-svn: 348524

  
Unlike some of the folds in hoistLogicOpWithSameOpcodeHands()
above this shuffle transform, this has the expected hasOneUse()
checks in place.

llvm-svn: 348523

This patch introduces a new DAGCombiner rule to simplify concat_vectors nodes:

concat_vectors( bitcast (scalar_to_vector %A), UNDEF)
    --> bitcast (scalar_to_vector %A)

This patch only partially addresses PR39257. In particular, it is enough to fix
one of the two problematic cases mentioned in PR39257. However, it is not enough
to fix the original test case posted by Craig; that particular case would
probably require a more complicated approach (and knowledge about used bits).

Before this patch, we used to generate the following code for function PR39257
(-mtriple=x86_64 , -mattr=+avx):

vmovsd  (%rdi), %xmm0           # xmm0 = mem[0],zero
vxorps  %xmm1, %xmm1, %xmm1
vblendps        $3, %xmm0, %xmm1, %xmm0 # xmm0 = xmm0[0,1],xmm1[2,3]
vmovaps %ymm0, (%rsi)
vzeroupper
retq

Now we generate this:

vmovsd  (%rdi), %xmm0           # xmm0 = mem[0],zero
vmovaps %ymm0, (%rsi)
vzeroupper
retq

As a side note: that VZEROUPPER is completely redundant...

I guess the vzeroupper insertion pass doesn't realize that the definition of
%xmm0 from vmovsd is already zeroing the upper half of %ymm0. Note that on
%-mcpu=btver2, we don't get that vzeroupper because pass vzeroupper insertion
%pass is disabled.

Differential Revision: https://reviews.llvm.org/D55274

llvm-svn: 348522

Summary:
Explicitly casted printf's args to the required types + simplified
shfl64 function.

Reviewers: gtbercea, kkwli0

Subscribers: guansong, jfb, caomhin, openmp-commits

Differential Revision: https://reviews.llvm.org/D55379

llvm-svn: 348521

The tests were marked to fail based on the 'availability' LIT feature.
However, those tests should really only be failing when we run them
against the dylibs that were deployed on macosx10.7 and macosx10.8,
which the deployment target has nothing to do with.

This caused the tests to unexpectedly pass when running the tests
with deployment target macosx10.{7,8} but running with a recent dylib.

llvm-svn: 348520

llvm-svn: 348519

The PPC test with 2 extra uses seems clearly better by avoiding this transform. 
With 1 extra use, we also prevent an extra register move (although that might
be an RA problem). The general rule should be to only make a change here if
it is always profitable. The x86 diffs are all neutral.

llvm-svn: 348518

llvm-svn: 348517

llvm-svn: 348516

The flag -fdebug-compilation-dir is useful to make generated .o files
independent of the path of the build directory, without making the compile
command-line dependent on the path of the build directory, like
-fdebug-prefix-map requires. This change makes it so that the driver can
forward the flag to -cc1as, like it already can for -cc1. We might want to
consider making -fdebug-compilation-dir a driver flag in a follow-up.

(Since -fdebug-compilation-dir defaults to PWD, it's already possible to get
this effect by setting PWD, but explicit compiler flags are better than env
vars, because e.g. ninja tracks command lines and reruns commands that change.)

Somewhat related to PR14625.

Differential Revision: https://reviews.llvm.org/D55377

llvm-svn: 348515

llvm-svn: 348514

This reverts commit r348280 and reapplies D55085 without modifications.

Original commit message:

    Avoid emitting redundant or unusable directories in DIFile metadata entries.

    As discussed on llvm-dev recently, Clang currently emits redundant
    directories in DIFile entries, such as

      .file      1 "/Volumes/Data/llvm" "/Volumes/Data/llvm/tools/clang/test/CodeGen/debug-info-abspath.c"

    This patch looks at any common prefix between the compilation
    directory and the (absolute) file path and strips the redundant
    part. More importantly it leaves the compilation directory empty if
    the two paths have no common prefix.

    After this patch the above entry is (assuming a compilation dir of "/Volumes/Data/llvm/_build"):

      .file 1 "/Volumes/Data/llvm" "tools/clang/test/CodeGen/debug-info-abspath.c"

    When building the FileCheck binary with debug info, this patch makes
    the build artifacts ~1kb smaller.

    Differential Revision: https://reviews.llvm.org/D55085

llvm-svn: 348513

This reverts commit r348203 and reapplies D55085 with an additional
GCOV bugfix to make the change NFC for relative file paths in .gcno files.

Thanks to Ilya Biryukov for additional testing!

Original commit message:

    Update Diagnostic handling for changes in CFE.

    The clang frontend no longer emits the current working directory for
    DIFiles containing an absolute path in the filename: and will move the
    common prefix between current working directory and the file into the
    directory: component.

    https://reviews.llvm.org/D55085

llvm-svn: 348512

In compile-and-link mode, the user doesn't specify the name of the
object files to generate, because there could be multiple inputs
on a single command line and this would be hard to specify.  So the
script just tries to be smart and figure out the best object file
names.  However, if two build scripts are running in parallel and
using the same source files as input, they would previously race
to write the same object files, since the computed name only considered
the source file names when computing the object file names.

With this patch, we also consider the final executable name.  In a
way, this "namespaces" the generated object files so that as long
as the final executable file names don't clash, the intermediate
object file names won't clash either.

llvm-svn: 348511

Fix predicate for arithmetic instructions with shift and/or extend.

llvm-svn: 348510

The standard section [array.zero] requires the return value of begin()
and end() methods of a zero-sized array to be unique. Eric Fiselier
clarifies: "That unique value cannot be null, and must be properly aligned".
This patch adds checks for the first part of this clarification: unique
value returned by these methods cannot be null.

Reviewed as https://reviews.llvm.org/D55366.
Thanks to Andrey Maksimov for the patch.

llvm-svn: 348509

The AVX512 diffs are neutral, but the bswap test shows a clear overreach in 
hoistLogicOpWithSameOpcodeHands(). If we don't check for other uses, we can 
increase the instruction count.

This could also fight with transforms trying to go in the opposite direction 
and possibly blow up/infinite loop. This might be enough to solve the bug 
noted here:
http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20181203/608593.html

I did not add the hasOneUse() checks to all opcodes because I see a perf 
regression for at least one opcode. We may decide that's irrelevant in the
face of potential compiler crashing, but I'll see if I can salvage that first.

llvm-svn: 348508

Some people are still running the test suite using AppleClang 9.

llvm-svn: 348507

llvm-svn: 348506

llvm-svn: 348505

This just extends D40453 (r319317) to Ubuntu.

Reviewed By: Hahnfeld, tra

Differential Revision: https://reviews.llvm.org/D55269

llvm-svn: 348504

Tweak write_cmake_config.py to also handle variable references looking @FOO@
(matching CMake's configure_file() function), and make it replace '\' 'n' in
values with a newline literal since there's no good portable way of passing a
real newline literal on a command line.

Use that to process all the .def.in files in llvm/include/Config and add
llvm/lib/Target/BUILD.gn, which (indirectly, through llvm-c/Target.h) includes
them.

Differential Revision: https://reviews.llvm.org/D55184

llvm-svn: 348503

llvm-svn: 348502

  
Added FIXME and TODO comments for lack of safety checks.
This function is a suspect in out-of-memory errors as discussed in
the follow-up thread to r347917:
http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20181203/608593.html

llvm-svn: 348501

Reviewers: krytarowski

Reviewed By: krytarowski

Differential Revision: https://reviews.llvm.org/D55354

llvm-svn: 348500

VarStreamArray was built on the assumption that it is backed by a
StreamRef, and offset 0 of that StreamRef is the first byte of the first
record in the array.

This is a logical and intuitive assumption, but unfortunately we have
use cases where it doesn't hold. Specifically, a PDB module's symbol
stream is prefixed by 4 bytes containing a magic value, and the first
byte of record data in the array is actually at offset 4 of this byte
sequence.

Previously, we would just truncate the first 4 bytes and then construct
the VarStreamArray with the resulting StreamRef, so that offset 0 of the
underlying stream did correspond to the first byte of the first record,
but this is problematic, because symbol records reference other symbol
records by the absolute offset including that initial magic 4 bytes. So
if another record wants to refer to the first record in the array, it
would say "the record at offset 4".

This led to extremely confusing hacks and semantics in loading code, and
after spending 30 minutes trying to get some math right and failing, I
decided to fix this in the underlying implementation of VarStreamArray.
Now, we can say that a stream is skewed by a particular amount. This
way, when we access a record by absolute offset, we can use the same
values that the records themselves contain, instead of having to do
fixups.

Differential Revision: https://reviews.llvm.org/D55344

llvm-svn: 348499

Initial step towards making the function more generic (and probably move into SelectionDAG).

This is necessary to avoid massive codegen bloat for PR38243 (Add modulo rotate support to LowerRotate).

llvm-svn: 348498

Summary:
If the output of debug directives only is requested, we should drop
emission of ',debug' option from the target directive. Required for
supporting of nvprof profiler.

Reviewers: echristo

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D46061

llvm-svn: 348497

Partial Redundancy Elimination of GEPs prevents CodeGenPrepare from
sinking the addressing mode computation of memory instructions back
to its uses. The problem comes from the insertion of PHIs, which
confuse CGP and make it bail.

I've autogenerated the check lines of an existing test and added a
store instruction to demonstrate the motivation behind this change.
The store is now using the gep instead of a phi.

Differential Revision: https://reviews.llvm.org/D55009

llvm-svn: 348496

Summary:
We may end up with not emitted debug directives at the end of the module
emission. Patch fixes this problem emitting those last directives the
end of the module emission.

Reviewers: echristo

Subscribers: jholewinski, llvm-commits

Differential Revision: https://reviews.llvm.org/D54320

llvm-svn: 348495

llvm-svn: 348494

This patch splits backend features currently
hidden behind architecture versions.

For example, currently the only way to activate
complex numbers extension is targeting an v8.3
architecture, where after the patch this extension
can be added separately.

This refactoring is required by the new command lines proposal:
http://lists.llvm.org/pipermail/llvm-dev/2018-September/126346.html


Reviewers: DavidSpickett, olista01, t.p.northover

Subscribers: kristof.beyls, bryanpkc, javed.absar, pbarrio

Differential revision: https://reviews.llvm.org/D54633

--

It was reverted in rL348249 due a	build bot failure in one of the
regression tests:
http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/builds/14386

The problem seems to be that FileCheck behaves
different in windows and linux. This new patch
splits the test file in multiple,
and does more exact pattern matching attempting
to circumvent the issue.

llvm-svn: 348493

If the array section is based on pointer and this sections is mapped in
target region + then it is used in the inner parallel region, it also
must be globalized as the pointer itself is passed by value, not by
reference.

llvm-svn: 348492

Summary:
According to the standard, after memory flushing the changes in the
memory must be visible to all the threads in all teams. Patch fixes
this.

Reviewers: gtbercea, kkwli0

Subscribers: guansong, jfb, caomhin, openmp-commits

Differential Revision: https://reviews.llvm.org/D55370

llvm-svn: 348491