| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
| |
Use some new substitutions to avoid duplicating the tests for just
dropped flags. -fPIC/-fPIE/-fpic/-fpie do not make sense on Windows as
they can cause ELF-style PIC. Substitute away the flag on Windows.
This should repair the windows buildbots.
llvm-svn: 290571
|
|
|
|
|
|
|
|
|
|
|
| |
This mostly involved converting from grep to FileCheck and tidying up
the IR used.
In one case (invoke_test-3.ll) the test had become completely pointless
as we use 'resume' rather than 'unwind' now, and even then it did not
occur at the end of the line.
llvm-svn: 290570
|
|
|
|
|
|
|
|
|
|
|
|
| |
Windows uses PE/COFF which is inherently position independent. The use
of the PIC model is unnecessary. In fact, we would generate invalid
code using the ELF PIC model when PIC was enabled previously. Now that
we no longer accept -fPIC and -fpoc, this switches the internal
representation to the static model to permit us to make PIC modules
invalid when targeting Windows. This should not change the code
generation, only the internal state management.
llvm-svn: 290569
|
|
|
|
| |
llvm-svn: 290568
|
|
|
|
|
|
|
| |
dependent contexts when processing the template in C++11 and C++14, just like
we do in C++98 and C++1z. This allows us to diagnose invalid templates earlier.
llvm-svn: 290567
|
|
|
|
|
|
|
|
| |
add/sub/mul/div with rounding intrinsics into normal IR operations if the rounding mode is CUR_DIRECTION.
An earlier commit added support for unmasked scalar operations. At that time isel wouldn't generate an optimal sequence for masked operations, but that has now been fixed.
llvm-svn: 290566
|
|
|
|
|
|
|
|
| |
cases that don't have a CUR_DIRECTION rounding mode.
The CUR_DIRECTION case will be optimized in a future commit so this provides coverage for the other cases.
llvm-svn: 290565
|
|
|
|
|
|
| |
into masked instructions.
llvm-svn: 290564
|
|
|
|
|
|
|
|
| |
scalar arithmetic operations.
These particular sequences will be generated after a future change to teach InstCombine to turn masked scalar arithmetic intrinsics into native IR.
llvm-svn: 290563
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
inside of `InlineFunction`. Prior to this, call instructions are
specifically being rewritten and replaced within the inlined region,
invalidating some of the call sites.
Several of these regions are using the same technique to walk the
inlined region so this seems clearly safe up to this point.
I've also added a short circuit to the scan for call sites based on what
other code is doing.
With this, the most common crash I've found in the new inliner code is
fixed. I've turned it on for another test case that covers this
scenario.
I'll make my way through most of the other inliner test cases
just to get some easy coverage next.
llvm-svn: 290562
|
|
|
|
|
|
|
|
|
|
| |
Improved doxygen comments for the following intrinsics headers: __wmmintrin_pclmul.h, bmiintrin.h, emmintrin.h, f16cintrin.h, immintrin.h, mmintrin.h, pmmintrin.h, tmmintrin.h
Added \n commands to insert a line breaks where necessary, since one long line of documentation is nearly unreadable.
Formatted comments to fit into 80 chars.
In some cases added \a command in front of the parameter names to display them in italics.
llvm-svn: 290561
|
|
|
|
|
|
|
| |
given that they hard code specific triples that seems reasonable so add
the REQUIRES.
llvm-svn: 290560
|
|
|
|
|
|
| |
rounding intrinsics into normal IR operations if the rounding mode is CUR_DIRECTION.
llvm-svn: 290559
|
|
|
|
|
|
|
|
|
|
|
| |
This is kind of funny because I specifically did work to make this easy
and then it didn't actually get implemented.
I've also ported a set of tests that rely on this functionality to run
with the new PM as well as the old PM so that we don't mess this up in
the future.
llvm-svn: 290558
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
removing fully-dead comdats without removing dead entries in comdats
with live members.
This factors the core logic out of the current inliner's internals to
a reusable utility and leverages that in both places. The factored out
code should also be (minorly) more efficient in cases where we have very
few dead functions or dead comdats to consider.
I've added a test case to cover this behavior of the always inliner.
This is the last significant bug in the new PM's always inliner I've
found (so far).
llvm-svn: 290557
|
|
|
|
|
|
|
|
| |
and RelWithDebInfo in Cmake.rst
This is surprising to many people.
llvm-svn: 290556
|
|
|
|
|
|
|
|
| |
pattern easier to write.
Differential Revision: https://reviews.llvm.org/D28120
llvm-svn: 290555
|
|
|
|
|
|
|
|
| |
PMULDQ/PMULUDQ vXi64 instructions only use the even numbered v2Xi32 input elements which SimplifyDemandedVectorElts should try and use.
Differential Revision: https://reviews.llvm.org/D28119
llvm-svn: 290554
|
|
|
|
|
|
| |
wrapper.
llvm-svn: 290553
|
|
|
|
| |
llvm-svn: 290552
|
|
|
|
| |
llvm-svn: 290551
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Mostly use a bit more idiomatic C++ where we can,
so we can combine some things later.
Reviewers: davide
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D28111
llvm-svn: 290550
|
|
|
|
|
|
| |
Fixes PR/31472
llvm-svn: 290549
|
|
|
|
|
|
|
|
| |
NewGVN can be tested passing `-mllvm -enable-newgvn` to clang.
Differential Revision: https://reviews.llvm.org/D28059
llvm-svn: 290548
|
|
|
|
| |
llvm-svn: 290547
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current GVN algorithm folds unconditional branches to, it claims,
expose more PRE oportunities. The folding, if really needed,
(which is not sure, as it's not really proved it improves analysis)
can be done by an earlier cleanup pass instead of GVN itself.
Ack'ed/SGTM'd by Daniel Berlin.
Differential Revision: https://reviews.llvm.org/D28117
llvm-svn: 290546
|
|
|
|
| |
llvm-svn: 290545
|
|
|
|
| |
llvm-svn: 290544
|
|
|
|
| |
llvm-svn: 290543
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D28110
llvm-svn: 290542
|
|
|
|
| |
llvm-svn: 290541
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Updated test according to commit 290539:
According to extended asm syntax, a case where the clobber list includes a variable from the inputs or outputs should be an error - conflict.
for example:
const long double a = 0.0;
int main()
{
char b;
double t1 = a;
__asm__ ("fucompp": "=a" (b) : "u" (t1), "t" (t1) : "cc", "st", "st(1)");
return 0;
}
This should conflict with the output - t1 which is st, and st which is st aswell.
The patch fixes it.
Commit on behald of Ziv Izhar.
Differential Revision: https://reviews.llvm.org/D15075
llvm-svn: 290540
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
According to extended asm syntax, a case where the clobber list includes a variable from the inputs or outputs should be an error - conflict.
for example:
const long double a = 0.0;
int main()
{
char b;
double t1 = a;
__asm__ ("fucompp": "=a" (b) : "u" (t1), "t" (t1) : "cc", "st", "st(1)");
return 0;
}
This should conflict with the output - t1 which is st, and st which is st aswell.
The patch fixes it.
Commit on behald of Ziv Izhar.
Differential Revision: https://reviews.llvm.org/D15075
llvm-svn: 290539
|
|
|
|
|
|
|
| |
This update improves isl's ability to coalesce different convex sets/maps,
especially when the contain existentially quantified variables.
llvm-svn: 290538
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
systematically and document in the test what all is going on.
This replaces the PR-named test that was the only coverage for GlobalDCE
and comdats previously. I wrote this because I wasn't certain how
comdat DCE was supposed to work and wanted to step through what
GlobalDCE did to fully understand it. After talking to folks and reading
the code and really staring at things it all makes sense but it seemed
good to help write down some of this in a more explicit and fully
covering test case.
For example, it seemed like a bug that GlobalDCE didn't consider comdat
participation of ifuncs. Specifically it seemed like an accident because
testing didn't really cover that case. But in fact, ifuncs specifically
cannot participate in a comdat despite having that API. The new test
case covers this and explicitly documents that DCE gets to fire here
even though there are comdats involved.
Also, we didn't have any positive tests for the challenging cases such
as usage cycles between comdat participants that might make them seem
alive except that there is no external edge into the cycle.
llvm-svn: 290537
|
|
|
|
| |
llvm-svn: 290536
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
rounding intrinsics into normal IR operations if the rounding mode is CUR_DIRECTION.
Summary:
I only do this for unmasked cases for now because isel is failing to fold the mask. I'll try to fix that soon.
I'll do the same thing for packed add/sub/mul/div in a future patch.
Reviewers: delena, RKSimon, zvi, craig.topper
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D27879
llvm-svn: 290535
|
|
|
|
| |
llvm-svn: 290534
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use of these flags would result in the use of ELF-style PIE/PIC code
which is incorrect on Windows. Windows is inherently PIC by means of
the DLL slide that occurs at load. This also mirrors the behaviour on
GCC for MinGW. Currently, the Windows x86_64 forces the relocation
model to PIC (Level 2). This is unchanged for now, though we should
remove any assumptions on that and change it to a static relocation
model.
llvm-svn: 290533
|
|
|
|
|
|
|
|
| |
constant. While clang will guarantee this, nothing in the backend will.
A non-constant value will now result in an isel error instead of just asserting or crashing due to a bad cast during lowering.
llvm-svn: 290532
|
|
|
|
| |
llvm-svn: 290531
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
intrinsics into shufflevector instructions
Summary:
This patch adds support for converting the masked vpermv intrinsics into shufflevector instructions if the indices are constants.
We also need to wrap a select instruction around the shuffle to take care of the masking part. InstCombine will take care of optimizing the select if the mask is constant so I didn't bother checking for that.
Reviewers: zvi, delena, spatel, RKSimon
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D27825
llvm-svn: 290530
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D26619
llvm-svn: 290529
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This recommits r290512 that was reverted when MSVC failed to compile it. Since
then I've played with various approaches using rextester.com (where I was able
to reproduce the failure) and think that I have a solution thanks in part to
the help of Dave Blaikie! It seems MSVC just has a defective `decltype` in this
version. Manually writing out the type seems to do the trick, even though it is
.... quite complicated.
Original commit message:
This allows both defining convenience iterator/range accessors on types
which walk across N different independent ranges within the object, and
more direct and simple usages with range based for loops such as shown
in the unittest. The same facilities are used for both. They end up
quite small and simple as it happens.
I've also switched an iterator on `Module` to use this. I would like to
add another convenience iterator that includes even more sequences as
part of it and seeing this one already present motivated me to actually
abstract it away and introduce a general utility.
Differential Revision: https://reviews.llvm.org/D28093
llvm-svn: 290528
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D26661
llvm-svn: 290527
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D27034
llvm-svn: 290526
|
|
|
|
|
|
|
|
|
|
|
|
| |
are equivalent (IE store of same value to memory).
Reviewers: davide
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D28084
llvm-svn: 290525
|
|
|
|
|
|
| |
of LLVM
llvm-svn: 290524
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
multiple asynchronous RPC calls.
ParallelCallGroup allows multiple asynchronous calls to be dispatched,
and provides a wait method that blocks until all asynchronous calls have
been executed on the remote and all return value handlers run on the
local machine.
This will allow, for example, the JIT client to issue memory allocation calls
for all sections in parallel, then block until all memory has been allocated
on the remote and the allocated addresses registered with the client, at which
point the JIT client can proceed to applying relocations.
llvm-svn: 290523
|
|
|
|
|
|
| |
different-width int.
llvm-svn: 290522
|