These lines all exist identically either under SSE2, AVX2 or AVX512. Given that VLX implies all of those, these aren't providing anything new.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319124 91177308-0d34-0410-b5e6-96231b3b80d8
With AVX512 vXi1 types are legal so we shouldn't be extending them.
This change is similar to existing code in the zext(setcc) combine.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319120 91177308-0d34-0410-b5e6-96231b3b80d8
This will allow a future F_Delete flag to be specified when we want
the file to be automatically deleted on close.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319117 91177308-0d34-0410-b5e6-96231b3b80d8
Which VTs are considered simple is determined by the superset of the legal types of all targets in LLVM. If we're looking at VTs that are going to be split down to 512-bits we should allow any VT not just simple ones since the simple list changes over time as new targets are added.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319110 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319105 91177308-0d34-0410-b5e6-96231b3b80d8
The previous implementation would only look 1 DW_AT_specification or DW_AT_abstract_origin deep. This means DWARFDie::getName() would fail in certain cases. I ran into such a case while creating a tool that used the LLVM DWARF parser to generate a symbolication format so I have seen this in the wild.
Differential Revision: https://reviews.llvm.org/D40156
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319104 91177308-0d34-0410-b5e6-96231b3b80d8
We don't do this for narrow vectors under AVX or SSE features. We also don't set them to Expand like we do for many vectors op. Nor does TargetLoweringBase.cpp. This leads me to believe these default to Legal.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319103 91177308-0d34-0410-b5e6-96231b3b80d8
This tries to propagate !range metadata to a pre-existing load
when a load is optimized out. This is done instead of adding an
assume because converting loads to and from assumes creates a
lot of IR.
Patch by Ariel Ben-Yehuda.
Differential Revision: https://reviews.llvm.org/D37216
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319096 91177308-0d34-0410-b5e6-96231b3b80d8
With this change, instead of creating a SectionChunk for each section
in the object file, we only create them when we encounter a prevailing
comdat section.
Also change how symbol resolution occurs between comdat symbols. Now
only the comdat leader participates in comdat resolution, and not any
other external associated symbols. This is more in line with how COFF
semantics are defined, and should allow for a more straightforward
implementation of non-ANY comdat types.
On my machine, this change reduces our runtime linking a release
build of chrome_child.dll with /nopdb from 5.65s to 4.54s (median of
50 runs).
Differential Revision: https://reviews.llvm.org/D40238
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319090 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds a peep hole optimization to remove any redundant toc save
instructions added as part of the call sequence for indirect calls. It removes
any toc saves within a function that are dominated by another toc save.
Differential Revision: https://reviews.llvm.org/D39736
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319087 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319082 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319075 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319071 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319070 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319069 91177308-0d34-0410-b5e6-96231b3b80d8
I don't believe our current lowering/combining would ever produce such a node. We only produce integer typed pshufds.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319068 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319066 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319059 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319049 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319044 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319036 91177308-0d34-0410-b5e6-96231b3b80d8
