This eliminates one overload on the term Raw.

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

llvm-svn: 293104

llvm-svn: 293102

Document the current practice regarding dropping metadata on modules,
functions and global variables.

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

llvm-svn: 293101

llvm-svn: 293100

Mach-O files don’t have size information about the symbols in the object file
format unlike ELF.

Also add the part of the fix to llvm-nm that was missed with r290001 so
-arch armv7m works.

rdar://25681018

llvm-svn: 293099

debugserver-mini can't use Foundation so disable that code there. 

llvm-svn: 293098

Summary:
Now when you ask clang to link in a bitcode module, you can tell it to
set attributes on that module's functions to match what we would have
set if we'd emitted those functions ourselves.

This is particularly important for fast-math attributes in CUDA
compilations.

Each CUDA compilation links in libdevice, a bitcode library provided by
nvidia as part of the CUDA distribution.  Without this patch, if we have
a user-function F that is compiled with -ffast-math that calls a
function G from libdevice, F will have the unsafe-fp-math=true (etc.)
attributes, but G will have no attributes.

Since F calls G, the inliner will merge G's attributes into F's.  It
considers the lack of an unsafe-fp-math=true attribute on G to be
tantamount to unsafe-fp-math=false, so it "merges" these by setting
unsafe-fp-math=false on F.

This then continues up the call graph, until every function that
(transitively) calls something in libdevice gets unsafe-fp-math=false
set, thus disabling fastmath in almost all CUDA code.

Reviewers: echristo

Subscribers: hfinkel, llvm-commits, mehdi_amini

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

llvm-svn: 293097

llvm-svn: 293096

llvm-svn: 293095

This is the patch upstreaming the device-agnostic part of libomptarget.

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

llvm-svn: 293094

It now uses the same infrastructure as symbol versions. This fixes us
creating a dynamic relocation without a corresponding dynamic symbol.

This also means that unlike gold and bfd we keep a STB_LOCAL in the
static symbol table. It seems an odd feature to offer precise control
over what is in a symbol table that is not used by the dynamic
linker. We can bring this back if needed, but it would probably be
better to just have --discard option that tells the linker to keep in
the static symbol table only what is in the dynamic one.

Should fix the eog build.

llvm-svn: 293093

This reverts commit r292680. It is causing significantly worse
performance and test timeouts in our internal builds. I have already
routed reproduction instructions your way.

llvm-svn: 293092

llvm-svn: 293091

This is not a list of pairs, it is a hash table data structure. We now
correctly parse this out and dump it from llvm-pdbdump.

We still need to understand the conditions that lead to a type
getting an entry in the hash adjuster table.  That will be done
in a followup investigation / patch.

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

llvm-svn: 293090

llvm-svn: 293089

Later code expects the vector loads produced to be directly
concatenable, which means we shouldn't pad anything except the last load
produced with UNDEF.

llvm-svn: 293088

Thanks to Quentin for suggesting the refactoring.

llvm-svn: 293087

I think it's a hold-over from some previous iteration, but it's never
set to true in LLVM as it exists now.

llvm-svn: 293086

Summary:
This is the first in a series of patches to add a simple, generalized updater to MemorySSA.

For MemorySSA, every def is may-def, instead of the normal must-def.
(the best way to think of memoryssa is "everything is really one variable, with different versions of that variable at different points in the program).
This means when updating, we end up having to do a bunch of work to touch defs below and above us.

In order to support this quickly, i have ilist'd all the defs for each block.  ilist supports tags, so this is quite easy. the only slightly messy part is that you can't have two iplists for the same type that differ only whether they have the ownership part enabled or not, because the traits are for the value type.

The verifiers have been updated to test that the def order is correct.

Reviewers: george.burgess.iv

Subscribers: llvm-commits

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

llvm-svn: 293085

While at it, also remove unused command line options.

llvm-svn: 293084

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

llvm-svn: 293083

Summary:
This patch provides a trampoline for function tail exit tracing. Still, it's staging because code `1` is passed to the handler function (indicating a normal exit) instead of `2`, which would indicate tail exit. This is so until the logging part of XRay supports tail exits too.
Related: https://reviews.llvm.org/D28947 (LLVM)

Reviewers: dberris, rengolin

Reviewed By: rengolin

Subscribers: aemerson, llvm-commits, iid_iunknown

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

llvm-svn: 293082

According to the documentation this is supposed to be -1
if indirect calls are not supported.

llvm-svn: 293081

Summary:
This patch prepares more for tail call support in XRay. Until the logging part supports tail calls, this is just staging, so it seems LLVM part is mostly ready with this patch.
Related: https://reviews.llvm.org/D28948 (compiler-rt)

Reviewers: dberris, rengolin

Reviewed By: dberris

Subscribers: llvm-commits, iid_iunknown, aemerson

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

llvm-svn: 293080

llvm-svn: 293079

Set LLVM_LIBRARY_OUTPUT_INTDIR as expected by llvm_setup_rpath() macro
when doing stand-alone builds. This is required to pass correct
-rpath-link when linking shared libraries, and therefore ensure that
the linker can find dependency libraries correctly during the build.

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

llvm-svn: 293078

llvm-svn: 293077

llvm-svn: 293076

This reverts commit r293033, per Danny's comment.  In short, we require
domtrees to have roots at all times.

llvm-svn: 293075

Change getReservedRegs() to not mark a register as reserved and then
revert that decision in some cases. Motivated by the discussion in
https://reviews.llvm.org/D29056

llvm-svn: 293073

llvm-svn: 293071

This patch adds support for the proc_bind clause on the Spmd construct
'target parallel' on the NVPTX device.  Since the parallel region is created
upon kernel launch, this clause can be safely ignored on the NVPTX device at
codegen time for level 0 parallelism.

Reviewers: ABataev
Differential Revision: https://reviews.llvm.org/D29128

llvm-svn: 293069

Summary:
Adding ARM64 as a supported architecture for Scudo.
The random shuffle is not yet supported for SizeClassAllocator32, which is used
by the AArch64 allocator, so disable the associated test for now.

Reviewers: kcc, alekseyshl, rengolin

Reviewed By: rengolin

Subscribers: aemerson, mgorny, llvm-commits

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

llvm-svn: 293068

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

llvm-svn: 293067

This has not reliably worked on powerpc since r279664.  Re-enable this
once the problem is tracked down and fixed.

llvm-svn: 293066

llvm-svn: 293065

This patch introduces guard based loop predication optimization. The new LoopPredication pass tries to convert loop variant range checks to loop invariant by widening checks across loop iterations. For example, it will convert

  for (i = 0; i < n; i++) {
    guard(i < len);
    ...
  }

to

  for (i = 0; i < n; i++) {
    guard(n - 1 < len);
    ...
  }

After this transformation the condition of the guard is loop invariant, so loop-unswitch can later unswitch the loop by this condition which basically predicates the loop by the widened condition:

  if (n - 1 < len)
    for (i = 0; i < n; i++) {
      ...
    } 
  else
    deoptimize

This patch relies on an NFC change to make ScalarEvolution::isMonotonicPredicate public (revision 293062).

Reviewed By: sanjoy

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

llvm-svn: 293064

llvm-svn: 293063

Will be used by the upcoming LoopPredication optimization.

llvm-svn: 293062

This is a partial fix for Bug 31520 - [guards] canonicalize guards in instcombine

Reviewed By: apilipenko

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

Patch by Maxim Kazantsev.

llvm-svn: 293061