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
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319030 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319025 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319019 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319016 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319014 91177308-0d34-0410-b5e6-96231b3b80d8
The check is actually unnecessary since AVX512VBMI implies AVX512BW which is the other part of the assert.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319006 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
For a given loop, getLoopLatch returns a non-null value
when a loop has only one latch block. In the modified
context adding an assertion to check that both the outgoing branches of
a terminator instruction (of latch) does not target same header.
+
few minor code reorganization.
Reviewers: jbhateja
Reviewed By: jbhateja
Subscribers: sanjoy
Differential Revision: https://reviews.llvm.org/D40460
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@318997 91177308-0d34-0410-b5e6-96231b3b80d8
Shadow stack solution introduces a new stack for return addresses only.
The HW has a Shadow Stack Pointer (SSP) that points to the next return address.
If we return to a different address, an exception is triggered.
The shadow stack is managed using a series of intrinsics that are introduced in this patch as well as the new register (SSP).
The intrinsics are mapped to new instruction set that implements CET mechanism.
The patch also includes initial infrastructure support for IBT.
For more information, please see the following:
https://software.intel.com/sites/default/files/managed/4d/2a/control-flow-enforcement-technology-preview.pdf
Differential Revision: https://reviews.llvm.org/D40223
Change-Id: I4daa1f27e88176be79a4ac3b4cd26a459e88fed4
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@318996 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
For a given loop, getLoopLatch returns a non-null value
when a loop has only one latch block. In the modified
context a check on both the outgoing branches of a terminator instruction (of latch) to same header is redundant.
Reviewers: jbhateja
Reviewed By: jbhateja
Subscribers: sanjoy
Differential Revision: https://reviews.llvm.org/D40460
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@318991 91177308-0d34-0410-b5e6-96231b3b80d8
(this header is not fully implemented (the out of line function
writeTypeRecordKind is called in an inline function but never
implemented - this fails to link under modular code generation) and not
included anywhere)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@318987 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
These instructions zero the non-scalar part of the lower 128-bits which makes them different than the FMA3 instructions which pass through the non-scalar part of the lower 128-bits.
I've only added fmadd because we should be able to derive all other variants using operand negation in the intrinsic header like we do for AVX512.
I think there are still some missed negate folding opportunities with the FMA4 instructions in light of this behavior difference that I hadn't noticed before.
I've split the tests so that we can use different intrinsics for scalar testing between the two. I just copied the tests split the RUN lines and changed out the scalar intrinsics.
fma4-fneg-combine.ll is a new test to make sure we negate the fma4 intrinsics correctly though there are a couple TODOs in it.
Reviewers: RKSimon, spatel
Reviewed By: RKSimon
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D39851
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@318984 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This adds a new fast gather feature bit to cover all CPUs that support fast gather that we can use independent of whether the AVX512 feature is enabled. I'm only using this new bit to qualify AVX2 codegen. AVX512 is still implicitly assuming fast gather to keep tests working and to match the scatter behavior.
Test command lines have been added for these two cases.
Reviewers: magabari, delena, RKSimon, zvi
Reviewed By: RKSimon
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D40282
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@318983 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Currently ScalarizeVecRes_SETCC checks for the result type being a vector and jumps to ScalarizeVecRes_VSETCC. But if we're scalarizing a vector result, aren't we guaranteed to be looking at a vector type?
This patch deletes the current ScalarizeVecRes_SETCC and renames ScalarizeVecRes_VSETCC to ScalarizeVecRes_SETCC.
Reviewers: RKSimon, arsenm, eladcohen, zvi
Reviewed By: RKSimon
Subscribers: wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D40452
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@318982 91177308-0d34-0410-b5e6-96231b3b80d8
Other checks inside require a build_vector, but we this lets us stop earlier and makes the code more clear.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@318969 91177308-0d34-0410-b5e6-96231b3b80d8
v4i32 isn't a legal type with sse1 only and would end up getting scalarized otherwise.
This isn't completely ideal as it doesn't handle cases like v8i32 that would get split to v4i32. But it at least helps with code written using the clang intrinsic header.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@318967 91177308-0d34-0410-b5e6-96231b3b80d8