to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

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

This is a follow-up to r351448. It adds support for other _*Z extensions
of the Itanium demanling, to the newly available demangle function
heuristic.

Reviewed by: erik.pilkington, rupprecht, grimar

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

llvm-svn: 351551

Summary:
The operators simply print the underlying value or "None".

The trickier part of this patch is making sure the streaming operators
work even in unit tests (which was my primary motivation, though I can
also see them being useful elsewhere). Since the stream operator was a
template, implicit conversions did not kick in, and our gtest glue code
was explicitly introducing an implicit conversion to make sure other
implicit conversions do not kick in :P. I resolve that by specializing
llvm_gtest::StreamSwitch for llvm:Optional<T>.

Reviewers: sammccall, dblaikie

Reviewed By: sammccall

Subscribers: mgorny, dexonsmith, kristina, llvm-commits

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

llvm-svn: 351548

This allows it to be used in an upcoming llvm-readobj change.

A small change in internal behaviour of the function is to always call
the microsoftDemangle function if the string does not have an itanium
encoding prefix, rather than only if it starts with '?'. This is
harmless because the microsoftDemangle function does the same check
already.

Reviewed by: grimar, erik.pilkington

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

llvm-svn: 351448

Summary:
The version of make_absolute which accepted a specific directory to use
as the "base" for the computation could never fail, even though it
returned a std::error_code. The reason for that seems to be historical
-- the CWD flavour (which can fail due to failure to retrieve CWD) was
there first, and the new version was implemented by extending that.

This removes the error return value from the non-CWD overload and
reimplements the CWD version on top of that. This enables us to remove
some dead code where people were pessimistically trying to handle the
errors returned from this function.

Reviewers: zturner, sammccall

Subscribers: hiraditya, kristina, llvm-commits

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

llvm-svn: 351317

llvm-svn: 351297

https://reviews.llvm.org/D52803

This patch adds support to continuously CSE instructions during
each of the GISel passes. It consists of a GISelCSEInfo analysis pass
that can be used by the CSEMIRBuilder.

llvm-svn: 351283

This adds support for multilib paths for wasm32 targets, following
[Debian's Multiarch conventions], and also adds an experimental OS name in
order to test it.

[Debian's Multiarch conventions]: https://wiki.debian.org/Multiarch/

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

llvm-svn: 351163

This reverts commit r351079, r351069 and r351050 as it broken the greendragon bots on macOS.

llvm-svn: 351091

Summary:
This patch drops install targets for LLVMHello.so,
TestPlugin.so, and BugpointPasses.so.

Reviewers: chandlerc, beanz, thakis, philip.pfaffe

Reviewed By: chandlerc

Subscribers: SquallATF, mgorny, llvm-commits

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

llvm-svn: 351087

llvm-svn: 351079

Summary:
Previously only one RealFileSystem instance was available, and its working
directory is shared with the process. This doesn't work well for multithreaded
programs that want to work with relative paths - the vfs::FileSystem is assumed
to provide the working directory, but a thread cannot control this exclusively.

The new vfs::createPhysicalFileSystem() factory copies the process's working
directory initially, and then allows it to be independently modified.

This implementation records the working directory path, and glues it to relative
paths to provide the correct absolute path to the sys::fs:: functions.
This will give different results in unusual situations (e.g. the CWD is moved).

The main alternative is the use of openat(), fstatat(), etc to ask the OS to
resolve paths relative to a directory handle which can be kept open. This is
more robust. There are two reasons not to do this initially:
1. these functions are not available on all supported Unixes, and are somewhere
   between difficult and unavailable on Windows. So we need a path-based
   fallback anyway.
2. this would mean also adding support at the llvm::sys::fs level, which is a
   larger project. My clearest idea is an OS-specific `BaseDirectory` object
   that can be optionally passed to functions there. Eventually this could be
   backed by either paths or a fd where openat() is supported.
   This is a large project, and demonstrating here that a path-based fallback
   works is a useful prerequisite.

There is some subtlety to the path-manipulation mechanism:
  - when setting the working directory, both Specified=makeAbsolute(path) and
    Resolved=realpath(path) are recorded. These may differ in the presence of
    symlinks.
  - getCurrentWorkingDirectory() and makeAbsolute() use Specified - this is
    similar to the behavior of $PWD and sys::path::current_path
  - IO operations like openFileForRead use Resolved. This is similar to the
    behavior of an openat() based implementation, that doesn't see changes
    in symlinks.
There may still be combinations of operations and FS states that yield unhelpful
behavior. This is hard to avoid with symlinks and FS abstractions :(

The caching behavior of the current working directory is removed in this patch.
getRealFileSystem() is now specified to link to the process CWD, so the caching
is incorrect.
The user who needed this so far is clangd, which will immediately switch to
createPhysicalFileSystem().

Reviewers: ilya-biryukov, bkramer, labath

Subscribers: ioeric, kadircet, kristina, llvm-commits

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

llvm-svn: 351050

Summary:
Add support for options that always prefix their value, giving an error
if the value is in the next argument or if the option is given a value
assignment (ie. opt=val). This is the desired behavior for the -D option
of FileCheck for instance.

Copyright:
- Linaro (changes in version 2 of revision D55940)
- GraphCore (changes in later versions and introduced when creating
  D56549)

Reviewers: jdenny

Subscribers: llvm-commits, probinson, kristina, hiraditya,
JonChesterfield

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

llvm-svn: 351038

This shortcut mechanism for creating types was added 10 years ago, but
has seen almost no uptake since then, neither internally nor in
external projects.

The very small number of characters saved by using it does not seem
worth the mental overhead of an additional type-creation API, so,
delete it.

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

llvm-svn: 351020

Complete the feature set for Exynos M4 and update test cases.

llvm-svn: 350953

On AIX, attempting (without root) to set the sticky bit on a file with
the `chmod` utility will give:
```
chmod: not all requested changes were made to <file>
```

The same occurs when modifying other permission bits on a file with the
sticky bit already set.

It seems that the `chmod` function will report success despite failing
to set the sticky bit.

llvm-svn: 350735

Prediction control instructions are only
mandatory from v8.5a onwards but is optional
from Armv8.0-A. This patch adds a command
line option to enable it by it's own.

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

llvm-svn: 350385

llvm-svn: 350351

This makes the target name consistent with how all the other unit tests are
named.

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

llvm-svn: 350339

SB (Speculative Barrier) is only mandatory from 8.5
onwards but is optional from Armv8.0-A. This patch adds a command
line option to enable SB, as it was previously only possible to
enable by selecting -march=armv8.5-a.

This patch also renames FeatureSpecRestrict to FeatureSB.

Reviewed By: olista01, LukeCheeseman

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

llvm-svn: 350299

SB (Speculative Barrier) is only mandatory from 8.5
onwards but is optional from Armv8.0-A. This patch adds a command
line option to enable SB, as it was previously only possible to
enable by selecting -march=armv8.5-a.

This patch also moves to FeatureSB the old FeatureSpecRestrict.

Reviewers: pbarrio, olista01, t.p.northover, LukeCheeseman	

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

llvm-svn: 350126

Summary:
Added a pair of APIs for encoding/decoding the 3 components of a DWARF discriminator described in http://lists.llvm.org/pipermail/llvm-dev/2016-October/106532.html: the base discriminator, the duplication factor (useful in profile-guided optimization) and the copy index (used to identify copies of code in cases like loop unrolling)

The encoding packs 3 unsigned values in 32 bits. This CL addresses 2 issues:
- communicates overflow back to the user
- supports encoding all 3 components together. Current APIs assume a sequencing of events. For example, creating a new discriminator based on an existing one by changing the base discriminator was not supported.

Reviewers: davidxl, danielcdh, wmi, dblaikie

Reviewed By: dblaikie

Subscribers: zzheng, dmgreen, aprantl, JDevlieghere, llvm-commits

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

llvm-svn: 349973

llvm-svn: 349963

Weak symbols are supposed to be supported in the ELF TextAPI
implementation, but the YAML handler didn't read or write the `Weak`
member of ELFSymbol. This change adds the YAML mapping and updates tests
to ensure correct behavior.

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

llvm-svn: 349950

Continues the work started by @bogner in rL340594 to remove uses of the KnownBits output paramater version.

llvm-svn: 349908

Summary:
This function checks whether the mappings in the interval map overlap
with the given range [a;b]. The motivation is to enable checking for
overlap before inserting a new interval into the map.

Reviewers: vsk, dblaikie

Subscribers: dexonsmith, kristina, llvm-commits

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

llvm-svn: 349898

Summary:
This function is very similar to add_llvm_library(),  so this patch merges it
into add_llvm_library() and replaces all calls to add_llvm_loadable_module(lib ...)
with add_llvm_library(lib MODULE ...)

Reviewers: philip.pfaffe, beanz, chandlerc

Reviewed By: philip.pfaffe

Subscribers: chapuni, mgorny, llvm-commits

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

llvm-svn: 349839

llvm-svn: 349760

We need to keep the underlying profile reader alive as long as the
profile data, because the profile data may contain StringRefs referring
to strings in the reader's name table.

llvm-svn: 349600

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

llvm-svn: 349410

Fixes:
  * find_last/find_last_unset - off-by-one error
  * Compound assignment ops and operator== when mixing big/small modes

Patch by Brad Moody
Differential Revision: https://reviews.llvm.org/D54933

llvm-svn: 349173

Summary:
This allows us to register it with the MachineFunction delegate and be
notified automatically about erasure and creation of instructions. However,
we still need explicit notification for modifications such as those caused
by setReg() or replaceRegWith().

There is a catch with this though. The notification for creation is
delivered before any operands can be added. While appropriate for
scheduling combiner work. This is unfortunate for debug output since an
opcode by itself doesn't provide sufficient information on what happened.
As a result, the work list remembers the instructions (when debug output is
requested) and emits a more complete dump later.

Another nit is that the MachineFunction::Delegate provides const pointers
which is inconvenient since we want to use it to schedule future
modification. To resolve this GISelWorkList now has an optional pointer to
the MachineFunction which describes the scope of the work it is permitted
to schedule. If a given MachineInstr* is in this function then it is
permitted to schedule work to be performed on the MachineInstr's. An
alternative to this would be to remove the const from the
MachineFunction::Delegate interface, however delegates are not permitted
to modify the MachineInstr's they receive.

In addition to this, the observer has three interface changes.
* erasedInstr() is now erasingInstr() to indicate it is about to be erased
  but still exists at the moment.
* changingInstr() and changedInstr() have been added to report changes
  before and after they are made. This allows us to trace the changes
  in the debug output.
* As a convenience changingAllUsesOfReg() and
  finishedChangingAllUsesOfReg() will report changingInstr() and
  changedInstr() for each use of a given register. This is primarily useful
  for changes caused by MachineRegisterInfo::replaceRegWith()

With this in place, both combine rules have been updated to report their
changes to the observer.

Finally, make some cosmetic changes to the debug output and make Combiner
and CombinerHelp

Reviewers: aditya_nandakumar, bogner, volkan, rtereshin, javed.absar

Reviewed By: aditya_nandakumar

Subscribers: mgorny, rovka, kristof.beyls, llvm-commits

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

llvm-svn: 349167

Summary:
In addition to knowing that an instruction is changed. It's also useful to
know when it's about to change. For example, it might print the instruction so
you can track the changes in a debug log, it might remove it from some queue
while it's being worked on, or it might want to change several instructions as
a single transaction and act on all the changes at once.

Added changingInstr() to all existing uses of changedInstr()

Reviewers: aditya_nandakumar

Reviewed By: aditya_nandakumar

Subscribers: rovka, kristof.beyls, llvm-commits

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

llvm-svn: 348992

Summary:
There's little of interest that can be done to an already-erased instruction.
You can't inspect it, write it to a debug log, etc. It ought to be notification
that we're about to erase it. Rename the function to clarify the timing of the
event and reflect current usage.

Also fixed one case where we were trying to print an erased instruction.

Reviewers: aditya_nandakumar

Reviewed By: aditya_nandakumar

Subscribers: rovka, kristof.beyls, llvm-commits

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

llvm-svn: 348976

IR-printing AfterPass instrumentation might be called on a loop
that has just been invalidated. We should skip printing it to
avoid spurious asserts.

Reviewed By: chandlerc, philip.pfaffe
Differential Revision: https://reviews.llvm.org/D54740

llvm-svn: 348887

This change makes DT_SONAME treated as an optional trait for ELF TextAPI
stubs. This change accounts for the fact that shared objects aren't
guaranteed to have a DT_SONAME entry. Tests have been updated to check
for correct behavior of an optional soname.

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

llvm-svn: 348817

https://reviews.llvm.org/D55294

Previously MachineIRBuilder::buildInstr used to accept variadic
arguments for sources (which were either unsigned or
MachineInstrBuilder). While this worked well in common cases, it doesn't
allow us to build instructions that have multiple destinations.
Additionally passing in other optional parameters in the end (such as
flags) is not possible trivially. Also a trivial call such as

B.buildInstr(Opc, Reg1, Reg2, Reg3)
can be interpreted differently based on the opcode (2defs + 1 src for
unmerge vs 1 def + 2srcs).
This patch refactors the buildInstr to

buildInstr(Opc, ArrayRef<DstOps>, ArrayRef<SrcOps>)
where DstOps and SrcOps are typed unions that know how to add itself to
MachineInstrBuilder.
After this patch, most invocations would look like

B.buildInstr(Opc, {s32, DstReg}, {SrcRegs..., SrcMIBs..});
Now all the other calls (such as buildAdd, buildSub etc) forward to
buildInstr. It also makes it possible to build instructions with
multiple defs.
Additionally in a subsequent patch, we should make it possible to add
flags directly while building instructions.
Additionally, the main buildInstr method is now virtual and other
builders now only have to override buildInstr (for say constant
folding/cseing) is straightforward.

Also attached here (https://reviews.llvm.org/F7675680) is a clang-tidy
patch that should upgrade the API calls if necessary.

llvm-svn: 348815

A dependency on TestingSupport was introduced in rL348735 but
library was not incldued in the LLVM_LINK_LLVM_DYLIB build.

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

llvm-svn: 348803

Summary: The APFloat and Constant APIs taking an APInt allow arbitrary payloads,
and that's great. There's a convenience API which takes an unsigned, and that's
silly because it then directly creates a 64-bit APInt. Just change it to 64-bits
directly.

At the same time, add ConstantFP NaN getters which match the APFloat ones (with
getQNaN / getSNaN and APInt parameters).

Improve the APFloat testing to set more payload bits.

Reviewers: scanon, rjmccall

Subscribers: jkorous, dexonsmith, kristina, llvm-commits

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

llvm-svn: 348791