Since this isn't a real header - it includes static functions and had
external linkage variables (though this change makes them static, since
that's what they should be) so can't be included more than once in a
program.

llvm-svn: 319082

llvm-svn: 319081

This breaks one of the unit tests. Need to find a good solution.

llvm-svn: 319076

enum TailCallKind { TCK_None = 0, TCK_Tail = 1, TCK_MustTail = 2,
                    TCK_NoTail = 3 };

TCK_NoTail is greater than TCK_Tail so taking the min does not do the
correct thing.

rdar://35639547

llvm-svn: 319075

Detects whether we have the Python modules (pygments, yaml) required by
opt-viewer and hooks this up to REQUIRES.

This fixes https://bugs.llvm.org/show_bug.cgi?id=34129 (the lack of opt-viewer
testing).

It's also related to https://github.com/apple/swift/pull/12938 and the idea is
to expose LLVM_HAVE_OPT_VIEWER_MODULES to the Swift cmake.

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

llvm-svn: 319073

llvm-svn: 319072

GNU's --strip-all doesn't strip as aggressively as it could in general.
Currently llvm-objcopy copies the exact behavoir of GNU's --strip-all.
eu-strip is used as a drop in replacement for GNU strip/objcopy in many many
places without issue. eu-strip removes non-allocated sections and keeps
.gnu.warning* sections. Because --strip-all will likely be the most widely
used stripping option we should make --strip-all as aggressive as it can safely
be. Since we have evidence from eu-strip that this is a safe option we should
allow it. For those that might still have an issue afterwards I've added
--strip-all-gnu as an exact drop in replacement for GNU's --strip-all as well.

llvm-svn: 319071

The existing library assumed that a stream's length would never
change.  This makes some things simpler, but it's not flexible
enough for what we need, especially for writable streams where
what you really want is for each call to write to actually append.

llvm-svn: 319070

Prevent unloading shared libraries on Linux when dlclose() is called.
This is necessary since command-line option parsing API relies on
registering the global option instances in the option parser instance
which can be loaded in a different shared library.

Given that we can't reliably remove those options when a library is
unloaded, the parser ends up containing dangling references. Since glibc
has relatively complex library unloading rules, some of the LLVM
libraries can be unloaded while others (including the Support library)
stay loaded causing quite a mayhem. To reliably prevent that, just
forbid unloading all libraries -- it's a very bad idea anyway.

While the issue arguably happens only with BUILD_SHARED_LIBS, it may
affect any library reusing llvm::cl interface.

Based on patch provided Ross Hayward on https://bugs.gentoo.org/617154.
Previously hit by Fedora back in Feb 2016:
https://lists.freedesktop.org/archives/mesa-dev/2016-February/107242.html

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

llvm-svn: 319069

I don't believe our current lowering/combining would ever produce such a node. We only produce integer typed pshufds.

llvm-svn: 319068

llvm-svn: 319067

I don't have a good test case for this at the moment. I was playing around with a change in legalizing and triggered this code to produce a PSHUFD with sse1 only.

llvm-svn: 319066

[X86][AVX512] Tag AVX512 PACKSS/PACKUS/PMADDWD/PMADDUBSW instructions with SSE_PACK/SSE_PMADD schedule classes

  

llvm-svn: 319065

llvm-svn: 319064

This shows several places where we fail to use masked move or blendm.

llvm-svn: 319063

mergeUseLists is implemented iteratively since r243590.

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

llvm-svn: 319061

[X86] Make getSetCCResultType return vXi1 for any vXi32/vXi64 vector over 512 bits long when AVX512 is enabled.

Similar for vXi16/vXi8 with BWI.

Any vector larger than 512 bits will be split to 512 bits during legalization. But without this we will fold sexts with them before that making it difficult to recover leading to scalarization.

llvm-svn: 319059

llvm-svn: 319054

See bug 35433: https://bugs.llvm.org/show_bug.cgi?id=35433

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

Reviewers: artem.tamazov, SamWot, arsenm
llvm-svn: 319050

This patch extends on to rL307174 to not use the power9 vector extract with
variable index instructions when extracting word element 1. For such cases,
the existing selection of MFVSRWZ provides a better sequence.

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

llvm-svn: 319049

Reviewers: dberris

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

llvm-svn: 319047

  

llvm-svn: 319045

DWARF4 relative DW_AT_high_pc values are now displayed as absolute
addresses. The relative value is only shown when explicitly dumping the
forms, i.e. in show-form or verbose mode.

```
DW_AT_low_pc	(0x0000000000000049)
DW_AT_high_pc	(0x00000019)
```

becomes

```
DW_AT_low_pc	(0x0000000000000049)
DW_AT_high_pc	(0x0000000000000062)
```

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

rdar://35416943

llvm-svn: 319044

llvm-svn: 319043

This is a superset of the tests proposed with D40012 to show another potential improvement.

llvm-svn: 319041

Summary:

Now that store-merge is only generates type-safe stores, do a second
pass just before instruction selection to allow lowered intrinsics to
be merged as well.

Reviewers: jyknight, hfinkel, RKSimon, efriedma, rnk, jmolloy

Subscribers: javed.absar, llvm-commits

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

llvm-svn: 319036

llvm-svn: 319031

Make the print format consistent with other assembler instructions.

Adding a tab character instead of space in asmstring of Ext and Ins
instructions.
Removing space around the tab character for JALRC and replacing space with
tab in JRC.

Patch by Milos Stojanovic.

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

llvm-svn: 319030

llvm-svn: 319029

llvm-svn: 319027

AMDGPU backend errors with "unsupported call to function" upon
encountering a call to llvm.log{,10}.{f16,f32} intrinsics. This patch
adds custom lowering to avoid that error on both R600 and SI.

Reviewers: arsenm, jvesely

Subscribers: tstellar

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

llvm-svn: 319025

The current way that trivial addressing modes are detected incorrectly thinks
that null pointers are non-trivial, leading to an infinite loop where we keep
duplicating the same select. Fix this by aware of null when deciding if an
addressing mode is trivial.

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

llvm-svn: 319019

llvm-svn: 319018

As mentioned on PR17367, many instructions are missing scheduling tags preventing us from setting 'CompleteModel = 1' for better instruction analysis. This patch deals with FMA/FMA4 which is one of the bigger offenders (along with AVX512 in general).

Annoyingly all scheduler models need to define WriteFMA (now that its actually used), even for older targets without FMA/FMA4 support, but that is an existing problem shared by other schedule classes.

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

llvm-svn: 319016

The commit https://reviews.llvm.org/rL318143 computes incorrectly to offset to
restore LR from.

The number of tPOP operands is 2 (condition) + 2 (implicit def and use of SP) +
count of the popped registers. We need to load LR from just past the last
register, hence the correct offset should be either getNumOperands() - 4 and
getNumExplicitOperands() - 2 (multiplied by 4).

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

llvm-svn: 319014

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

llvm-svn: 319013

[SelectionDAG] Teach SplitVecRes_SETCC to call GetSplitVector if the operands have already been split.

llvm-svn: 319010

llvm-svn: 319009

The check is actually unnecessary since AVX512VBMI implies AVX512BW which is the other part of the assert.

llvm-svn: 319006

llvm-svn: 319005