llvm-svn: 351635

a stray single '\r' from one file. These are the last line ending issues
I can find in the files containing parts of LLVM's file headers.

llvm-svn: 351634

code.

llvm-svn: 351633

endings. We already used them in some cases, and this makes things
consistent. This will also simplify updating the licenses in these
files.

llvm-svn: 351632

This installs the new developer policy and moves all of the license
files across all LLVM projects in the monorepo to the new license
structure. The remaining projects will be moved independently.

Note that I've left odd formatting and other idiosyncracies of the
legacy license structure text alone to make the diff easier to read.
Critically, note that we do not in any case *remove* the old license
notice or terms, as that remains necessary until we finish the
relicensing process.

I've updated a few license files that refer to the LLVM license to
instead simply refer generically to whatever license the LLVM project is
under, basically trying to minimize confusion.

This is really the culmination of so many people. Chris led the
community discussions, drafted the policy update and organized the
multi-year string of meeting between lawyers across the community to
figure out the strategy. Numerous lawyers at companies in the community
spent their time figuring out initial answers, and then the Foundation's
lawyer Heather Meeker has done *so* much to help refine and get us ready
here. I could keep going on, but I just want to make sure everyone
realizes what a huge community effort this has been from the begining.

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

llvm-svn: 351631

llvm-svn: 351630

  With commit r351627, LLVM gained the ability to apply (existing) IPO
  optimizations on indirections through callbacks, or transitive calls.
  The general idea is that we use an abstraction to hide the middle man
  and represent the callback call in the context of the initial caller.
  It is described in more detail in the commit message of the LLVM patch
  r351627, the llvm::AbstractCallSite class description, and the
  language reference section on callback-metadata.

  This commit enables clang to emit !callback metadata that is
  understood by LLVM. It does so in three different cases:
    1) For known broker functions declarations that are directly
       generated, e.g., __kmpc_fork_call for the OpenMP pragma parallel.
    2) For known broker functions that are identified by their name and
       source location through the builtin detection, e.g.,
       pthread_create from the POSIX thread API.
    3) For user annotated functions that carry the "callback(callee, ...)"
       attribute. The attribute has to include the name, or index, of
       the callback callee and how the passed arguments can be
       identified (as many as the callback callee has). See the callback
       attribute documentation for detailed information.

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

llvm-svn: 351629

This modification of the currently unused inter-procedural constant
propagation pass (IPConstantPropagation) shows how abstract call sites
enable optimization of callback calls alongside direct and indirect
calls. Through minimal changes, mostly dealing with the partial mapping
of callbacks, inter-procedural constant propagation was enabled for
callbacks, e.g., OpenMP runtime calls or pthreads_create.

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

llvm-svn: 351628

  An abstract call site is a wrapper that allows to treat direct,
  indirect, and callback calls the same. If an abstract call site
  represents a direct or indirect call site it behaves like a stripped
  down version of a normal call site object. The abstract call site can
  also represent a callback call, thus the fact that the initially
  called function (=broker) may invoke a third one (=callback callee).
  In this case, the abstract call side hides the middle man, hence the
  broker function. The result is a representation of the callback call,
  inside the broker, but in the context of the original instruction that
  invoked the broker.

  Again, there are up to three functions involved when we talk about
  callback call sites. The caller (1), which invokes the broker
  function. The broker function (2), that may or may not invoke the
  callback callee. And finally the callback callee (3), which is the
  target of the callback call.

  The abstract call site will handle the mapping from parameters to
  arguments depending on the semantic of the broker function. However,
  it is important to note that the mapping is often partial. Thus, some
  arguments of the call/invoke instruction are mapped to parameters of
  the callee while others are not. At the same time, arguments of the
  callback callee might be unknown, thus "null" if queried.

  This patch introduces also !callback metadata which describe how a
  callback broker maps from parameters to arguments. This metadata is
  directly created by clang for known broker functions, provided through
  source code attributes by the user, or later deduced by analyses.

For motivation and additional information please see the corresponding
talk (slides/video)
  https://llvm.org/devmtg/2018-10/talk-abstracts.html#talk20
as well as the LCPC paper
  http://compilers.cs.uni-saarland.de/people/doerfert/par_opt_lcpc18.pdf

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

llvm-svn: 351627

Original commit: r351582

llvm-svn: 351626

D56445 bumped the minimum Mac OS X version required for aligned
allocation from 10.13 to 10.14. This caused libc++ tests depending
on the old value to break.

This patch updates the XFAILs for those tests to include 10.13.

llvm-svn: 351625

Thanks to Nikita Popov for pointing out this missed case.

This is a follow-up to r351411, which disabled function merging for
vararg functions outright due to a miscompile (see llvm.org/PR40345).

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

llvm-svn: 351624

If an inherently cold function is found, mark it as cold. For now this
means applying the `cold` and `minsize` attributes.

As a drive-by, revisit and clean up the criteria for considering a
function for splitting. Add tests.

llvm-svn: 351623

Use the begin/end iterator idiom to avoid visiting split functions,
instead of doing a set lookup.

llvm-svn: 351622

CodeExtractor permits extracting a region of blocks from a function even
when values defined within the region are used outside of it.

This is typically done by creating an alloca in the original function
and reloading the alloca after a call to the extracted function.

Wrap the reload in lifetime start/end markers to promote stack coloring.

Suggested by Sergei Kachkov!

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

llvm-svn: 351621

Summary:
Whenever a large shadow region is tagged to zero, madvise(DONT_NEED)
as much of it as possible.

This reduces shadow RSS on Android by 45% or so, and total memory use
by 2-4%, probably even more on long running multithreaded programs.
CPU time seems to be in the noise.

Reviewers: kcc, pcc

Subscribers: srhines, kubamracek, llvm-commits

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

llvm-svn: 351620

This reverts commit r351618.

Compiler RT + ASAN tests are failing for PowerPC. Not sure
how would I reproduce these on macOS, so reverting (again)
until I do.

llvm-svn: 351619

Original commit: r351582

llvm-svn: 351618

This new assertion triggered on the AArch64 GlobalISel bots. Reverting while it's being investigated.

llvm-svn: 351617

Summary:
Right now we include ${TGT}GenCallingConv.inc once per each instruction
selection method implemented by ${TGT}:
- ${TGT}ISelLowering.cpp
- ${TGT}CallLowering.cpp
- ${TGT}FastISel.cpp

Instead, add a mechanism to tablegen for marking a particular convention
as "External", which causes tablegen to emit into the ::llvm namespace,
instead of as a static helper. This allows us to provide a header to
forward declare it, so we can simply call the function from all the
places it is referenced. Typically the calling convention analyzer is
called indirectly, so it doesn't benefit from inlining.

This saves a bit of final binary size, but mostly just saves object file
size:

before  after   diff   artifact
12852K  12492K  -360K  X86ISelLowering.cpp.obj
4640K   4280K   -360K  X86FastISel.cpp.obj
1704K   2092K   +388K  X86CallingConv.cpp.obj
52448K  52336K  -112K  llc.exe

I didn't collect before numbers for X86CallLowering.cpp.obj, which is
for GlobalISel, but we should save 360K there as well.

This patch applies the strategy to the X86 backend, but there is no
reason it couldn't be applied to the other backends that implement
multiple ISel strategies, like AArch64.

Reviewers: craig.topper, hfinkel, efriedma

Subscribers: javed.absar, kristof.beyls, hiraditya, llvm-commits

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

llvm-svn: 351616

r291284 added a nice mechanism to consistently pass CMake on/off toggles to
lit. This change uses it for LLVM_LIBXML2_ENABLED too (which was added around
the same time and doesn't use the new system yet).

Also alphabetically sort the list passed to llvm_canonicalize_cmake_booleans()
in llvm/test/CMakeLists.txt.

No intended behavior change.

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

llvm-svn: 351615

r291284 added a nice mechanism to consistently pass CMake on/off toggles to
lit. This change uses it for LLVM_LIBXML2_ENABLED too (which was added around
the same time and doesn't use the new system yet).

No intended behavior change.

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

llvm-svn: 351614

This code is dead. There is no use of the feature in the entire LLVM codebase.

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

llvm-svn: 351613

llvm-svn: 351612

We're seeing an odd issue on GreenDragon's lldb-cmake-matrix. Dotest is
unable to move a log file (OSError: [Errno 2] No such file or
directory). The os.rename call is guarded with a check that the source
file and destination directory exist.

This wraps the call in a try-except that prints the source and
destination path to see which component seemingly doesn't exist.

llvm-svn: 351611

Add a defensive check against an invalid destructor in the CFG.

Unions with fields with destructors have their own destructor implicitly
deleted. Due to a bug in the CFG we're still trying to evaluate them
at the end of the object's lifetime and crash because we are unable
to find the destructor's declaration.

rdar://problem/47362608

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

llvm-svn: 351610

If a property is defined with a custom getter, we should not behave as if
the getter simply returns an instance variable. We don't support setters,
so they aren't affected.

On top of being the right thing to do, this also fixes a crash on
the newly added test - in which a property and its getter are defined
in two separate categories.

rdar://problem/47051544

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

llvm-svn: 351609

Reviewers: krytarowski, eugenis

Subscribers: llvm-commits

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

llvm-svn: 351607

llvm-svn: 351606

llvm-svn: 351605

These conditions are duplicated from the dumpDeclContext function called
within the if(). This is presumably an attempt to avoid calling the
function in the case it will do nothing.

That may have made sense in the past if the code was different, but it
doesn't make sense now.

llvm-svn: 351604

llvm-svn: 351603

Reviewers: aaron.ballman

Subscribers: cfe-commits

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

llvm-svn: 351601

Summary:
Removal of the child node makes it easier to separate traversal from
output generation.

Reviewers: aaron.ballman

Subscribers: cfe-commits

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

llvm-svn: 351600

llvm-svn: 351599

This reverts commit r351582.

Bots are failing. Reverting this to fix and re-commit later.

llvm-svn: 351598

Summary:
This makes it easier to separate traversal of the AST from output
generation.

Reviewers: aaron.ballman

Subscribers: cfe-commits

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

llvm-svn: 351597

llvm-svn: 351596

As of r343360, we support fixed-enums in C. This lead to some
warnings in project headers where a fixed enum is forward declared
then later defined. In C++, this is fine, the forward declaration is
treated as a complete type even though the definition isn't present.
We use this rule in C too, but still warn about the forward
declaration anyways. This patch suppresses the warning.

rdar://problem/47356469

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

llvm-svn: 351595

llvm-svn: 351594