Deduce the "returned" argument attribute by collecting all potentially
returned values.

Not only the unique return value, if any, can be used by subsequent
attributes but also the set of all potentially returned values as well
as the mapping from returned values to return instructions that they
originate from (see AAReturnedValues::checkForallReturnedValues).

Change in statistics (-stats) for LLVM-TS + Spec2006, totaling ~19% more "returned" arguments.

  ADDED: attributor                   NumAttributesManifested                  n/a ->        637
  ADDED: attributor                   NumAttributesValidFixpoint               n/a ->      25545
  ADDED: attributor                   NumFnArgumentReturned                    n/a ->        637
  ADDED: attributor                   NumFnKnownReturns                        n/a ->      25545
  ADDED: attributor                   NumFnUniqueReturned                      n/a ->      14118
CHANGED: deadargelim                  NumRetValsEliminated                     470 ->        449 (    -4.468%)
REMOVED: functionattrs                NumReturned                              535 ->        n/a
CHANGED: indvars                      NumElimIdentity                          138 ->        164 (   +18.841%)

Reviewers: homerdin, hfinkel, fedor.sergeev, sanjoy, spatel, nlopes, nicholas, reames, efriedma, chandlerc

Subscribers: hiraditya, bollu, cfe-commits, llvm-commits

Tags: #clang, #llvm

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

llvm-svn: 365407

This is a fix for rG864949 which only disabled default construction and
assignment for lambdas with capture-defaults, where the C++2a draft
disables them for lambdas with any lambda-capture at all.

Patch by Logan Smith!

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

llvm-svn: 365406

This fixes a modules issue:

error: declaration of 'bitc' must be imported from module
'Clang_Serialization.ASTBitCodes' before it is required
Stream.EmitRecord(llvm::bitc::BLOCKINFO_CODE_SETBID, Record);

llvm-svn: 365405

Porting over the part of `emitComparison` in AArch64ISelLowering where we use
TST to represent a compare.

- Rename `tryOptCMN` to `tryFoldIntegerCompare`, since it now also emits TSTs
  when possible.

- Add a utility function for emitting a TST with register operands.

- Rename opt-fold-cmn.mir to opt-fold-compare.mir, since it now also tests the
  TST fold as well.

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

llvm-svn: 365404

Address post-commit feedback from Pavel and Jim.

llvm-svn: 365403

llvm-svn: 365402

This fixes buildbot failure in LLVM on llvm-clang-x86_64-expensive-checks-win
from r365386.

llvm-svn: 365401

This is possible now that the function returns an llvm::Expected

llvm-svn: 365400

There's no point to manually create the __start___sancov_guards and __stop___sancov_guards
sections and labels on Solaris any longer.  They were originally introduced in
https://reviews.llvm.org/D40899 and https://reviews.llvm.org/D40903.

- The Solaris 11.4 ld supports creating them out of the box.
- We already unconditionally use Solaris 11.4 features like the ld -z gnu-version-script-compat option and fully working .preinit_array support in compiler-rt.
- The current files don't assemble on SPARC because the assembler syntax may be different between /bin/as and GNU as.

Tested on amd64-pc-solaris2.11.

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

llvm-svn: 365399

This will help removing the custom load predicates, allowing the
global isel emitter to handle them.

llvm-svn: 365398

llvm-svn: 365397

As explained in https://reviews.llvm.org/D63601, there's no point using clang_rt.sancov_{begin,end}
on Solaris any longer.

This companion patch to the above removes their use from the driver.

Tested on amd64-pc-solaris2.11

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

llvm-svn: 365396

llvm-svn: 365395

llvm-svn: 365394

Revert [Sema] Resolve placeholder types before type deduction to silence spurious `-Warc-repeated-use-of-weak` warnings

This reverts r365382 (git commit 8b1becf2)

Appears to regress this semi-reduced fragment of valid code from windows
SDK headers:

  #define InterlockedIncrement64 _InterlockedIncrement64
  extern "C" __int64 InterlockedIncrement64(__int64 volatile *Addend);
  #pragma intrinsic(_InterlockedIncrement64)
  unsigned __int64 InterlockedIncrement(unsigned __int64 volatile *Addend) {
    return (unsigned __int64)(InterlockedIncrement64)((volatile __int64 *)Addend);
  }

Found on a buildbot here, but no mail was sent due to it already being
red:
http://lab.llvm.org:8011/builders/sanitizer-windows/builds/48067

llvm-svn: 365393

After discussing this internally, it is my understanding this was used
for building LLDB internally at Apple, and is no longer used or
necessary.

llvm-svn: 365392

As discussed offline, this tool is no longer used or maintained, and
doesn't provide the right abstraction for performance tracking in lldb.

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

llvm-svn: 365391

Create a std::error_code from the result of GetLastError, which in turn
we can use to return an llvm::Error.

llvm-svn: 365390

[lldb] Fix two more issues in Windows following rL365226: Change LaunchThread interface to return an expected

A couple of the function signatures changed and they were not updated in the Windows HostProcess

llvm-svn: 365388

Summary:
This makes it so that IR files using triples without an environment work
out of the box, without normalizing them.

Typically, the MSVC behavior is more desirable. For example, it tends to
enable things like constant merging, use of associative comdats, etc.

Addresses PR42491

Reviewers: compnerd

Subscribers: hiraditya, dexonsmith, llvm-commits

Tags: #llvm

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

llvm-svn: 365387

Currently llvm-profdata does not expect the same file name for the input profile
and the output profile.
>llvm-profdata merge A.profraw B.profraw -o B.profraw
The above command runs successfully but the resulted B.profraw is not correct.
This patch fixes the issue by moving the initialization of writer after loading
the profile.

For the show command, the following will report a confusing error of
"Empty raw profile file":
>llvm-profdata show B.profraw -o B.profraw
It's harder to fix as we need to output something before loading the input profile.
I don't think that a fix for this is worth the effort. I just make the error explicit for
the show command.

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

llvm-svn: 365386

Causes build failure on clang-ppc64be-linux-lnt:

compiler-rt/lib/asan/asan_malloc_win.cc:23:2: error: #error "Missing arch or unsupported platform for Windows."
 #error "Missing arch or unsupported platform for Windows."
  ^~~~~
compiler-rt/lib/asan/asan_malloc_win.cc:25:10: fatal error: heapapi.h: No such file or directory
 #include <heapapi.h>
          ^~~~~~~~~~~
compilation terminated.
[39/1151] Building CXX object projects/compiler-rt/lib/asan/CMakeFiles/RTAsan.powerpc64.dir/asan_debugging.cc.o
[40/1151] Building CXX object projects/compiler-rt/lib/asan/CMakeFiles/RTAsan.powerpc64.dir/asan_malloc_win.cc.o
FAILED: projects/compiler-rt/lib/asan/CMakeFiles/RTAsan.powerpc64.dir/asan_malloc_win.cc.o
/usr/bin/c++  -D_DEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Iprojects/compiler-rt/lib/asan -Icompiler-rt/lib/asan -Iinclude -I/home/buildbots/ppc64be-clang-lnt-test/clang-ppc64be-lnt/llvm/include -Icompiler-rt/lib/asan/.. -fPIC -fvisibility-inlines-hidden -Werror=date-time -std=c++11 -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wno-maybe-uninitialized -Wno-noexcept-type -Wdelete-non-virtual-dtor -Wno-comment -fdiagnostics-color -ffunction-sections -fdata-sections -Wall -std=c++11 -Wno-unused-parameter -O2    -UNDEBUG  -m64 -fPIC -fno-builtin -fno-exceptions -fomit-frame-pointer -funwind-tables -fno-stack-protector -fvisibility=hidden -fno-lto -O3 -g -Wno-variadic-macros -Wno-non-virtual-dtor -fno-rtti -MD -MT projects/compiler-rt/lib/asan/CMakeFiles/RTAsan.powerpc64.dir/asan_malloc_win.cc.o -MF projects/compiler-rt/lib/asan/CMakeFiles/RTAsan.powerpc64.dir/asan_malloc_win.cc.o.d -o projects/compiler-rt/lib/asan/CMakeFiles/RTAsan.powerpc64.dir/asan_malloc_win.cc.o -c compiler-rt/lib/asan/asan_malloc_win.cc
compiler-rt/lib/asan/asan_malloc_win.cc:23:2: error: #error "Missing arch or unsupported platform for Windows."
 #error "Missing arch or unsupported platform for Windows."
  ^~~~~
compiler-rt/lib/asan/asan_malloc_win.cc:25:10: fatal error: heapapi.h: No such file or directory
 #include <heapapi.h>
          ^~~~~~~~~~~

llvm-svn: 365384

llvm-ar.extract.test has been failing on greendragon and gone unfixed.

llvm-svn: 365383

spurious `-Warc-repeated-use-of-weak` warnings

The spurious -Warc-repeated-use-of-weak warnings are issued when an
initializer expression uses a weak ObjC pointer.

My first attempt to silence the warnings (r350917) caused clang to
reject code that is legal in C++17. The patch is based on the feedback I
received from Richard when the patch was reverted.

http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20190422/268945.html
http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20190422/268943.html

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

llvm-svn: 365382

   - Adds interceptors for Rtl[Allocate|Free|Size|ReAllocate]Heap
   - Adds unit tests for the new interceptors and expands HeapAlloc
     tests to demonstrate new functionality.
   Reviewed as D62927

llvm-svn: 365381

A test commit following 'Obtaining Commit Access' (https://llvm.org/docs/DeveloperPolicy.html#obtaining-commit-access)

llvm-svn: 365380

Forming the canonical splat shuffle improves analysis and
may allow follow-on transforms (although some possibilities
are missing as shown in the test diffs).

The backend generically turns these patterns into build_vector,
so there should be no codegen regressions. All targets are
expected to be able to lower splats efficiently.

llvm-svn: 365379

llvm-svn: 365378

This should fix the build under -Wundefined-func-template and certain
versions of GCC.

llvm-svn: 365377

Currently, the symbolizer lib can only symbolize a file on disk.
This patch teaches the symbolizer lib to symbolize objects.
llvm-objdump needs this to support archive disassembly with source info.

https://bugs.llvm.org/show_bug.cgi?id=41871

Reviewed by: jhenderson, grimar, MaskRay

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

llvm-svn: 365376

This reverts commit a2ca3582.

llvm-svn: 365375

Provide more data to the user in the error message about unsupported
type for device compilation.

llvm-svn: 365374

llvm-svn: 365373

Make the FP register callee saved.

This is tricky because now the FP needs to be spilled in the prolog
relative to the incoming SP register, rather than the frame register
used throughout the rest of the function. I don't like how this
bypassess the standard mechanism for CSR spills just to get the
correct insert point. I may look for a better solution, since all CSR
VGPRs may also need to have all lanes activated. Another option might
be to make getFrameIndexReference change the base register if the
frame index is a CSR, and then try to figure out the right insertion
point in emitProlog.

If there is a free VGPR lane available for SGPR spilling, try to use
it for the FP. If that would require intrtoducing a new VGPR spill,
try to use a free call clobbered SGPR. Only fallback to introducing a
new VGPR spill as a last resort.

This also doesn't attempt to handle SGPR spilling with scalar stores.

llvm-svn: 365372

This reverts commit 9c01eaff.

The changes in this commit are causing several of the LLDB tests to hang and/or timeout.

llvm-svn: 365371

This is extremly slow on AMDGPU, which has a lot of physical register
and a lot of register classes.

determineCalleeSaves, via MachineRegisterInfo::isPhysRegUsed already
added all of the super registers to the saved set.

llvm-svn: 365370

llvm-svn: 365369

Rename variable to follow LLVM coding standard.

llvm-svn: 365368

This reverts commit be414806.

llvm-svn: 365367

loop
Summary:
Do the cloning in two steps, first allocate all the new loops, then
clone the basic blocks in the same order as the original loop.
Reviewer: Meinersbur, fhahn, kbarton, hfinkel
Reviewed By: hfinkel
Subscribers: hfinkel, hiraditya, llvm-commits
Tag: https://reviews.llvm.org/D64224
Differential Revision:

llvm-svn: 365366