llvm-svn: 346394

The clang-cl driver disables access to command line options outside of the
"Core" and "CLOption" sets of command line arguments. This filtering makes it
impossible to pass arguments that are interpreted by the clang driver and not
by either 'cc1' (the frontend) or one of the other tools invoked by the driver.

An example driver-level flag is the '-fno-slp-vectorize' flag, which is
processed by the driver in Clang::ConstructJob and used to set the cc1 flag
"-vectorize-slp". There is no negative cc1 flag or -mllvm flag, so it is not
currently possible to disable the SLP vectorizer from the clang-cl driver.

This change introduces the "/clang:" argument that is available when the
driver mode is set to CL compatibility. This option works similarly to the
"-Xclang" option, except that the option values are processed by the clang
driver rather than by 'cc1'. An example usage is:

  clang-cl /clang:-fno-slp-vectorize /O2 test.c

Another example shows how "/clang:" can be used to pass a flag where there is
a conflict between a clang-cl compat option and an overlapping clang driver
option:

  clang-cl /MD /clang:-MD /clang:-MF /clang:test_dep_file.dep test.c

In the previous example, the unprefixed /MD selects the DLL version of the msvc
CRT, while the prefixed -MD flag and the -MF flags are used to create a make
dependency file for included headers.

One note about flag ordering: the /clang: flags are concatenated to the end of
the argument list, so in cases where the last flag wins, the /clang: flags
will be chosen regardless of their order relative to other flags on the driver
command line.

Patch by Neeraj K. Singh!

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

llvm-svn: 346393

Summary:
Documentation can be found at https://www.khronos.org/registry/OpenCL/extensions/intel/cl_intel_device_side_avc_motion_estimation.txt

Patch by Kristina Bessonova


Reviewers: Anastasia, yaxunl, shafik

Reviewed By: Anastasia

Subscribers: arphaman, sidorovd, AlexeySotkin, krisb, bader, asavonic, cfe-commits

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

llvm-svn: 346392

Reviewers: asl

Subscribers: llvm-commits

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

llvm-svn: 346391

LSR reassociates constants as unfolded offsets when the constants fit as
immediate add operands, which currently prevents such constants from being
combined later with loop invariant registers.
This patch modifies GenerateCombinations() to generate a second formula which
includes the unfolded offset in the combined loop-invariant register.

This commit fixes a bug in the original patch (committed at r345114, reverted
at r345123).

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

llvm-svn: 346390

We have a lot of various bugs that are caused by misuse of SCEV (in particular in LV),
all of them can simply be described as "we ask SCEV to prove some fact on invalid IR".
Some of examples of those are PR36311, PR37221, PR39160.

The problem is that these failues manifest differently (what we saw was failure of various
asserts across SCEV, but there can also be miscompiles). This patch adds an assert into two
SCEV methods that strongly rely on correctness of the IR and are involved in known failues.
This will at least allow us to have a clear indication of what was wrong in this case.

This patch also fixes a unit test with incorrect IR that fails this verification.

Differential Revision: https://reviews.llvm.org/D52930
Reviewed By: fhahn

llvm-svn: 346389

Summary: This instruction is useful for inspecting extractvalue/insertvalue in IR. Unlike most other operations, indices cannot be inspected using the generic Value.Opcode() function so a specialized function needs to be added.

Reviewers: whitequark, pcc

Reviewed By: whitequark

Subscribers: llvm-commits

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

llvm-svn: 346388

Summary:
The OCaml manual states:

> Local variables of type value must be declared with one of the
> CAMLlocal macros. [...] These macros must be used at the beginning
> of the function, not in a nested block.

This patch moves several instances of CAMLlocal macros from nested
blocks to the function beginning.

Reviewers: whitequark

Reviewed By: whitequark

Subscribers: CodaFi, llvm-commits

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

llvm-svn: 346387

Summary:
MergeFunctions currently tries to process strong functions before
weak functions, because weak functions can simply call strong
functions, while a strong/weak function cannot call a weak function
(a backing strong function is needed).

This patch additionally tries to process external functions before
local functions, because we definitely have to keep the external
function, but may be able to drop the local one (and definitely
can if it is also unnamed_addr).

Unfortunately, this exposes an existing bug in the implementation:
The FnTree and FNodesInTree structures can currently go out of
sync in the case where two weak functions are merged, because the
function in FnTree/FNodesInTree is RAUWed. This leaves it behind in
FnTree (this is intended, as it is the strong backing function which
should be used for further merges), while it is replaced in
FNodesInTree (this is not intended).

This is fixed by switching FNodesInTree from using a ValueMap to
using a DenseMap of AssertingVH.

This exposes another minor issue: Currently FNodesInTree is not
cleared after MergeFunctions finishes running. Currently, this is
potentially dangerous (e.g. if something else wants to RAUW a function
with a non-function), but at the very least it is unnecessary/inefficient.
After the change to use AssertingVH it becomes more problematic,
because there are certainly passes that remove functions.

This issue is fixed by clearing FNodesInTree at the end of the pass.

Reviewers: jfb, whitequark

Reviewed By: whitequark

Subscribers: rkruppe, llvm-commits

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

llvm-svn: 346386

Summary:
For unnamed_addr functions we RAUW instead of only replacing direct callers. However, functions in which replacements were performed currently are not added back to the worklist, resulting in missed merging opportunities.

Fix this by calling removeUsers() prior to RAUW.

Reviewers: jfb, whitequark

Reviewed By: whitequark

Subscribers: rkruppe, llvm-commits

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

llvm-svn: 346385

Reviewers: aheejin, dschuff

Subscribers: sbc100, jgravelle-google, sunfish, llvm-commits

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

llvm-svn: 346384

This reverts commit rL346367 due to test error in compiler-rt.

llvm-svn: 346383

Avoids linker errors about relocations against discarded sections.

This was uncovered during the Chromium clang roll here:
https://chromium-review.googlesource.com/c/chromium/src/+/1321863#message-717516acfcf829176f6a2f50980f7a4bdd66469a

After this change, Chromium's libGLESv2 links successfully for me.

Reviewers: metzman, hans, morehouse

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

llvm-svn: 346381

Turns out knowing more than just the base address might be useful -
specifically a future change to respect a DICompileUnit flag for the use
of base address specifiers in DWARF < 5.

llvm-svn: 346380

If a block doesn't have any ranges of adjacent legal instructions, then it
can't have outlining candidates. There's no point in mapping legal isntructions
in situations like this.

I noticed this reduces the size of the suffix tree in sqlite3 for AArch64 at
-Oz by about 3%.

llvm-svn: 346379

Make the check_include_file* macros honor CMAKE_REQUIRED_LIBRARIES. This
shouldn't cause any of the configuration checks to give different
results, and I verified that a clean configure before and after this
change resulted in identical CMake caches on my machine. The same change
was done for LLVM in r346377.

llvm-svn: 346378

Make the check_include_file* macros honor CMAKE_REQUIRED_LIBRARIES. This
shouldn't cause any of the configuration checks to give different
results (and I did clean configures before and after this change and
confirmed that the resulting CMake caches were identical, though of
course that's just one machine). This suppresses a warning when building
with CMake 3.12 or later.

This doesn't suppress the warning in clang, because clang does its own
cmake_minimum_required call even when being built in-tree, and that
resets all policy settings. I'll address that separately.

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

llvm-svn: 346377

Promote alloca can vectorize a small array by bitcasting it to a
vector type. Extend vectorization for the case when alloca is
already a vector type. We still want to replace GEPs with an
insert/extract element instructions in this case.

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

llvm-svn: 346376

Replace calls to LLVM's is_directory with calls to LLDB's FileSytem
class. For this I introduced a new convenience method that, like the
other methods, takes either a path or filespec. This still uses the LLVM
functions under the hood.

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

llvm-svn: 346375

Summary:
This change implements assembler parser, code emitter, ELF object writer
and disassembler for the MSP430 ISA.  Also, more instruction forms are added
to the target description.

Reviewers: asl

Reviewed By: asl

Subscribers: pftbest, krisb, mgorny, llvm-commits

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

llvm-svn: 346374

I noticed that there are lots of basic blocks that don't have enough legal
instructions in them to warrant outlining. We can skip mapping these entirely.

In sqlite3, compiled for AArch64 at -Oz, this results in a 10% reduction of
the total nodes in the suffix tree. These nodes can never be part of a
repeated substring, and so they don't impact the result at all.

Before this, there were 62128 nodes in the tree for sqlite3. After this, there
are 56457 nodes.

llvm-svn: 346373

Expose the `llvm::sys::fs::is_local` function through the VFS.

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

llvm-svn: 346372

Summary:
Port the GNU style printNotes method to the LLVMStyle subclass.

This is basically just a heavy refactor so that the note parsing/formatting logic from the GNUStyle::printNotes can be shared with LLVMStyle::printNotes.

Reviewers: MaskRay

Reviewed By: MaskRay

Subscribers: dschuff, fedor.sergeev, llvm-commits

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

llvm-svn: 346371

If all the edge counts for a function are zero, skip count population and
annotation, as nothing will happen. This can save some compile time.

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

llvm-svn: 346370

Reviewers: EricWF, ldionne, mclow.lists

Reviewed By: ldionne

Subscribers: christof, libcxx-commits

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

llvm-svn: 346369

llvm-svn: 346368

Summary:
Code in config-ix tries to call `PYTHON_EXECUTABLE` to search for some
python modules but that variable isn't set until the moved chunk of
code that finds Python is called.

Reorder it so CMake can use PYTHON_EXECUTABLE

Subscribers: mgorny, llvm-commits

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

llvm-svn: 346367

In this context, usesWindowsCFI() is basically the same thing as
isOSWindows(), but it makes the relevant property of the target
more explicit.

llvm-svn: 346366

DWARFContext.cpp:356:20: error: using the result of an assignment as a condition without parentheses [-Werror,-Wparentheses]

llvm-svn: 346365

This reverts commit r344696 for now (except for some test additions).

See https://bugs.freedesktop.org/show_bug.cgi?id=108611.

llvm-svn: 346364

Summary: Remove redundant logic and simplify control flow.

Reviewers: msearles, rampitec, scott.linder, kanarayan

Subscribers: arsenm, kzhuravl, jvesely, wdng, yaxunl, dstuttard, tpr, t-tye, llvm-commits

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

llvm-svn: 346363

Summary:
This is not needed, because we don't actually insert relevant branches
for KILLs that late in the compilation flow.

Besides, this was always checking for the wrong kill opcode anyway...

Reviewers: msearles, rampitec, scott.linder, kanarayan

Subscribers: arsenm, kzhuravl, jvesely, wdng, yaxunl, dstuttard, tpr, t-tye, llvm-commits

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

llvm-svn: 346362

llvm-svn: 346361

Type units go in .debug_info comdats, not .debug_types, in v5.

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

llvm-svn: 346360

llvm-svn: 346359

Like the comment says, this isn't the most efficient fix in terms of
codesize, but it works.

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

llvm-svn: 346358

llvm-svn: 346357

Summary:
D53821 fixed the bogus MSVC (at least 2017) C4146 warning (unary minus applied on unsigned type)
by using std::numeric_limits<int32_t>::min().
The warning was because -2147483648 is incorrectly treated as unsigned long instead of long long)

Let's use INT32_MIN which is arguably more readable.
Note, on GCC or clang, -0x80000000 works fine (ILP64: long, LP64: long long).

Reviewers: ruiu, jhenderson, sfertile, espindola

Reviewed By: sfertile

Subscribers: emaste, nemanjai, arichardson, kbarton, jsji, llvm-commits

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

llvm-svn: 346356

The lowering was missing live-ins in certain cases, like a sequence of
multiple tMOVCCr_pseudo instructions.  This would lead to a verifier
failure, and on pre-v6 Thumb CPSR would be incorrectly clobbered.

For reasons I don't completely understand, it's hard to get a sequence
of multiple tMOVCCr_pseudo instructions; the issue only seems to show up
with 64-bit comparisons where the result is zero-extended. I added some
extra testcases in case that changes in the future. Probably some
optimization opportunities here if anyone is interested. (@test_slt_not
is the case that was getting miscompiled.)

The code to check the liveness of CPSR was stolen from
X86ISelLowering.cpp; maybe it could be refactored into common helper,
but I have no idea where to put it.

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

llvm-svn: 346355

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

llvm-svn: 346354