| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
can see what compare instructions are being used in the lookup table code.
I noticed the 512-bit lzcnts don't use the X86 specific lookup table code and instead use the EXPAND case in LegalizeDAG. I was toying around with fixing this and noticed it would require compare instructions that generate i1 masks and then converting from mask to vector. Then I noticed that we don't test which compares are used with avx512vl and no avx512cd.
llvm-svn: 303020
|
| |
|
|
|
|
| |
Remove an unneeded prefix from the 32-bit command line. Make all the 64-bit triples match. Replace ALL with X64 and remove it from the 32-bit test.
llvm-svn: 303019
|
| |
|
|
| |
llvm-svn: 303018
|
| |
|
|
|
|
| |
sequences
llvm-svn: 303017
|
| |
|
|
|
|
|
|
|
| |
Revert the two commits to understand why the following aarch64 bot is
failing.
http://lab.llvm.org:8011/builders/libcxx-libcxxabi-libunwind-aarch64-linux
llvm-svn: 303016
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
After rL301562, on FreeBSD the DynamicLibrary unittests fail, because
the test uses getMainExecutable("DynamicLibraryTests", Ptr), and since
the path does not contain any slashes, retrieving the main executable
will not work.
Reimplement getMainExecutable() for FreeBSD and NetBSD using sysctl(3),
which is more reliable than fiddling with relative or absolute paths.
Also add retrieval of the original argv[] from the GoogleTest framework,
to use as a fallback for other OSes.
Reviewers: emaste, marsupial, hans, krytarowski
Reviewed By: krytarowski
Subscribers: krytarowski, llvm-commits
Differential Revision: https://reviews.llvm.org/D33171
llvm-svn: 303015
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Running `llvm-readobj -coff-directives msvcrt.lib` resulted in this error:
Invalid data was encountered while parsing the file
This happened because some of the object files in the archive have empty
`.drectve` sections. These empty sections result in a `parse_failed` error being
returned from `COFFObjectFile::getSectionContents()`, which in turn caused
`llvm-readobj` to stop. With this change, `getSectionContents` now returns
success, and like before the resulting array is empty.
Patch by Dave Lee.
Differential Revision: https://reviews.llvm.org/D32652
llvm-svn: 303014
|
| |
|
|
|
|
|
|
| |
mask.
Tweak cost model to match what lowering actually does.
llvm-svn: 303013
|
| |
|
|
| |
llvm-svn: 303012
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a very thin wrapper around StringRef::getAsInteger.
It serves three purposes.
1) It allows a cleaner syntax when you have something other than
a StringRef - for example, a std::string or an llvm::SmallString.
Previously, in this case you would have to write something like:
StringRef(MyStr).getAsInteger(0, Result)
by explicitly constructing a temporary StringRef. This can be
done implicitly however with the new function by just writing:
to_integer(MyStr, ...).
2) Correcting the travesty that is getAsInteger's return value.
This function returns true on success, and false on failure.
While this may cause confusion with people familiar with the
getAsInteger API, there seems to be widespread agreement that
the return semantics of getAsInteger was a mistake.
3) It allows the Radix to be deduced as a default argument by
putting it last in the parameter list. Most uses of getAsInteger
pass 0 for the first argument. With this syntax it can just be
omitted.
llvm-svn: 303011
|
| |
|
|
| |
llvm-svn: 303010
|
| |
|
|
|
|
| |
constant splats for vXi64 shifts.
llvm-svn: 303009
|
| |
|
|
|
|
| |
Shows issue with 32-bits not being able to peek through subvectors to extract constant splats
llvm-svn: 303008
|
| |
|
|
| |
llvm-svn: 303007
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
At the time of code generation, an instruction with an llvm intrinsic is ignored
in copyBB. However, if the value of the instruction is used later in the
program, the value needs to be synthesized. However, this is causing some issues
with the instructions being generated in a hoisted basic block.
Removing llvm.expect from the list of ignored intrinsics fixes this bug.
This resolves http://llvm.org/PR32324.
Contributed-by: Annanay Agarwal <cs14btech11001@iith.ac.in>
Tags: #polly
Differential Revision: https://reviews.llvm.org/D32992
llvm-svn: 303006
|
| |
|
|
| |
llvm-svn: 303005
|
| |
|
|
|
|
|
|
| |
its commuted variants.
We already had (A & ~B) | (A ^ B), but we missed the cases where the not was part of the xor.
llvm-svn: 303004
|
| |
|
|
| |
llvm-svn: 303003
|
| |
|
|
| |
llvm-svn: 303002
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The statement **getArg** tries to get the first one without checking, which may cause segmentation fault.
Reviewers: chh, bkramer
Reviewed By: bkramer
Subscribers: cfe-commits, xazax.hun
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D33103
llvm-svn: 303001
|
| |
|
|
| |
llvm-svn: 303000
|
| |
|
|
| |
llvm-svn: 302999
|
| |
|
|
| |
llvm-svn: 302998
|
| |
|
|
|
|
| |
demandedelts in ComputeNumSignBits
llvm-svn: 302997
|
| |
|
|
| |
llvm-svn: 302996
|
| |
|
|
|
|
|
| |
This reorganisation prevents us from cluttering up the top-level lib directory
with more driver libraries such as llvm-dlltool (see D29892).
llvm-svn: 302995
|
| |
|
|
|
|
| |
demandedelts support in ComputeNumSignBits
llvm-svn: 302994
|
| |
|
|
| |
llvm-svn: 302993
|
| |
|
|
| |
llvm-svn: 302992
|
| |
|
|
|
|
| |
ComputeSignBit. NFC
llvm-svn: 302991
|
| |
|
|
|
|
|
| |
Tests that use target intrinsics are inherently target specific. Mark
them as such.
llvm-svn: 302990
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Further perf tests on Jaguar indicate that:
vxorps %ymm0, %ymm0, %ymm0
vcmpps $15, %ymm0, %ymm0, %ymm0
is consistently faster (by about 9%) than:
vpcmpeqd %xmm0, %xmm0, %xmm0
vinsertf128 $1, %xmm0, %ymm0, %ymm0
Testing equivalent code on a SandyBridge (E5-2640) puts it slightly (~3%) faster as well.
Committed on behalf of @dtemirbulatov
Differential Revision: https://reviews.llvm.org/D32416
llvm-svn: 302989
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Loop vectorizer pass introduced undef value while it is fixing output of LCSSA form.
Here it is:
before: %e.0.ph = phi i32 [ 0, %for.inc.2.i ]
after: %e.0.ph = phi i32 [ 0, %for.inc.2.i ], [ undef, %middle.block ]
and after this change we have:
%e.0.ph = phi i32 [ 0, %for.inc.2.i ]
%e.0.ph = phi i32 [ 0, %for.inc.2.i ], [ 0, %middle.block ]
Committed on behalf of @dtemirbulatov
Differential Revision: https://reviews.llvm.org/D33055
llvm-svn: 302988
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Removal of overwritten writes currently encompasses all the cases
of the identical write removal.
There is an observable behavioral change in that the last, instead
of the first, MemoryAccess is kept. This should not affect the
generated code, however.
Differential Revision: https://reviews.llvm.org/D33143
llvm-svn: 302987
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove memory writes that are overwritten by later writes. This works
for StoreInsts:
store double 21.0, double* %A
store double 42.0, double* %A
scalar writes at the end of a statement and mixes of these.
Multiple writes can be the result of DeLICM, which might map multiple
writes to the same location when it knows that these do no conflict
(for instance because they write the same value). Such writes
interfere with pattern-matched optimization such as gemm and may not
get removed by other LLVM passes after code generation.
Differential Revision: https://reviews.llvm.org/D33142
llvm-svn: 302986
|
| |
|
|
| |
llvm-svn: 302985
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
- MIRYamlMapping: Default value provided for fields which have optional
mappings. Implemented == operators for required classes. When a field's value is
same as default value specified YAML IO class will not print it.
- MIRPrinter: Above mentioned behaviour is not on by default. If -simplify-mir
option not specified, then make yaml::Output to print fields with default values
too.
Differential Revision: https://reviews.llvm.org/D32304
llvm-svn: 302984
|
| |
|
|
| |
llvm-svn: 302983
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
something changed in the initial Worklist creation
Summary:
If the Worklist build causes an IR change this change flag currently factors into the flag for running another iteration of the iteration loop. But only changes during processing should trigger another loop.
This patch captures the worklist creation change flag into the outside the loop flag currently used for DbgDeclares and only sends that flag up to the caller. Rerunning the loop only depends on IC.run() now.
This uses the debug output of InstCombine to determine if one or two iterations run. I couldn't think of a better way to detect it since the second spurious iteration shoudn't make any visible changes. Just wasted computation.
I can do a pre-commit of the test case with the CHECK-NOT as a CHECK if this is an ok way to check this.
This is a subset of D31678 as I'm still not sure how to verify the analysis behavior for that.
Reviewers: davide, majnemer, spatel, chandlerc
Reviewed By: davide
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D32453
llvm-svn: 302982
|
| |
|
|
|
|
|
|
|
| |
For ARM EHABI, _Unwind_Exception is an alias of _Unwind_Control_Block,
which is not aligned, so we shouldn't align unwindHeader either.
rdar://problem/25364625
llvm-svn: 302981
|
| |
|
|
|
|
|
| |
This allows us to mark this as `REQUIRES: x86`, since it uses x86
target specific intrinsics.
llvm-svn: 302980
|
| |
|
|
|
|
|
|
| |
Tests with target intrinsics are inherently target specific, so it
doesn't actually make sense to run them if we've excluded their
target.
llvm-svn: 302979
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r276215 made a change to annotate _Unwind_Exception with attribute
"aligned" so that an exception object following field __cxa_exception
is sufficiently aligned. This fix hasn't been incorporated to unwind.h
on Darwin since it is an ABI breaking change.
Instead of annotating struct _Unwind_Exception with the attribute, this
commit annotates field unwindHeader of __cxa_exception. This ensures the
exception object is sufficiently aligned without breaking the ABI.
This recommits r302763 with fixes to RUN lines in the test case.
rdar://problem/25364625
Differential Revision: https://reviews.llvm.org/D33030
llvm-svn: 302978
|
| |
|
|
| |
llvm-svn: 302977
|
| |
|
|
|
|
|
|
|
|
| |
I bet the change is correct but this test seems to expose some underlying
problem that manifest only on some buildbots, and I'm not able to reproduce
locally. Unfortunately I can't debug right now but I don't want to annoy
people with spurious failures, so I'll XFAIL until I can take a look (over
the weekend).
llvm-svn: 302976
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ASTImporter has some bugs when it's importing types
that themselves come from an ExternalASTSource. This
is exposed particularly in the behavior when
comparing complete TagDecls with forward
declarations. This patch does several things:
- Adds a test case making sure that conflicting
forward-declarations are resolved correctly;
- Extends the clang-import-test harness to test
two-level importing, so that we make sure we
complete types when necessary; and
- Fixes a few bugs I found this way. Failure to
complete types was one; however, I also discovered
that complete RecordDecls aren't properly added to
the redecls chain for existing forward
declarations.
llvm-svn: 302975
|
| |
|
|
| |
llvm-svn: 302974
|
| |
|
|
|
|
|
|
|
|
| |
Contributed by Dr. Gergő Érdi.
Fixes a bug.
Raised from (https://github.com/avr-rust/rust/issues/49).
llvm-svn: 302973
|
| |
|
|
|
|
|
|
|
| |
Update a few tests to use llvm.masked.load/store instead of arm neon
vector loads and stores, and move the tests that are actually specific
to those arm intrinsics to their own files. This lets us mark the
tests that use target specific intrinsics as requiring those targets.
llvm-svn: 302972
|
| |
|
|
| |
llvm-svn: 302971
|