| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 322464
|
| |
|
|
| |
llvm-svn: 322463
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
scalar operations
Summary: This patch changes the kunpck intrinsic autoupgrade to use vXi1 shufflevector operations to perform vector extracts and concats. This more closely matches the definition of the kunpck instructions. Currently we rely on a DAG combine to turn the scalar shift/and/or code into a concat vectors operation. By doing it in the IR we get this for free.
Reviewers: spatel, RKSimon, zvi, jina.nahias
Reviewed By: RKSimon
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D42018
llvm-svn: 322462
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
integer shift/and/or
Summary:
kunpck intrinsics were removed in favor of native IR a few months ago. The implementation lowers them as by operation on the integer types passed to the intrinsic and then just shifting, masking, and oring them together. A special X86 DAG combine was added to recognize this patter and turn it into a concat_vector operation.
I think it makes more sense to keep the IR implementation closer to vector operations on vXi1. Given that we expect these builtins to be used around other builtins that operate on k-registers which we try to represent in IR with vXi1. InstCombine should be able to get rid of the bitcasts between integers and vXi1 leaving only the vector operations.
Reviewers: RKSimon, spatel, zvi, jina.nahias
Reviewed By: RKSimon
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D42016
llvm-svn: 322461
|
| |
|
|
| |
llvm-svn: 322460
|
| |
|
|
| |
llvm-svn: 322459
|
| |
|
|
|
|
| |
Shows a missed opportunity to remove a unnecessary move compared to 31 shuffle mask.
llvm-svn: 322458
|
| |
|
|
| |
llvm-svn: 322457
|
| |
|
|
| |
llvm-svn: 322456
|
| |
|
|
|
|
| |
types have the same number of elements.
llvm-svn: 322455
|
| |
|
|
|
|
|
|
| |
We have to take special care to avoid the cases where the result of the truncate would be padded with zero elements.
Ideally we'd just use ISD::TRUNCATE for these cases instead.
llvm-svn: 322454
|
| |
|
|
|
|
|
|
|
| |
parseInt assumed that it could take a negative number literal (e.g.
"-123"). However, such number is in reality already handled as a
unary operator '-' followed by a number literal, so the number
literal is always non-negative. Thus, this code is dead.
llvm-svn: 322453
|
| |
|
|
|
|
|
|
|
| |
This is related to moving the sanitizer blacklists to share/
subdirectory.
Differential Revision: https://reviews.llvm.org/D41706
llvm-svn: 322452
|
| |
|
|
|
|
|
|
|
|
|
| |
Currently these files are being installed into a root installation
directory, but this triggers an error when the installation directory
is set to an empty string which is often the case when DESTDIR is
used to control the installation destination.
Differential Revision: https://reviews.llvm.org/D41673
llvm-svn: 322451
|
| |
|
|
|
|
|
|
| |
Extend vXi1 conditions of vXi8/vXi16 selects even before type legalization gets a chance to split wide vectors. Previously we would only extend 128 and 256 bit vectors. But if we start with a 512 bit vector or wider that needs to be split we wouldn't extend until after the split had taken place. By extending early we improve the results of type legalization.
Don't widen condition of 128/256 bit vXi16/vXi8 selects when we have BWI but not VLX. We can still use a mask register by widening the select to 512-bits instead. This is similar to what we do for compares already.
llvm-svn: 322450
|
| |
|
|
|
|
|
|
| |
additional test cases.
Additional test cases cover selects with i16/i8 conditions that are only 128/256-bits wide, but the compares are 512-bits wide and can only produce k-registers. We should be able to artificially widen the selects to avoid moving the k-register to an xmm/ymm register.
llvm-svn: 322449
|
| |
|
|
|
|
| |
Remove inaccurate comment that came in with r312125.
llvm-svn: 322448
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Use monospace for option flags in the PCH section, instead of the
italics that were being used previously.
I believe these used to be links, for which single backticks would
have been appropriate, but since they were un-link-ified in
https://reviews.llvm.org/rL275560, I believe monospace is now more
appropriate, and so two backticks are needed.
Test Plan:
Build the `docs-clang-html` target and confirm the options are rendered
using monospace font.
Reviewers: sepavloff, aaron.ballman
Reviewed By: aaron.ballman
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D42005
llvm-svn: 322447
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In addition to the existing match as part of a loop-reduction, add a
straightforward pattern match for DAG-contained patterns.
Reviewers: RKSimon, craig.topper
Subscribers: llvm-commits
Reviewed By: RKSimon
Differential Revision: https://reviews.llvm.org/D41811
llvm-svn: 322446
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In https://reviews.llvm.org/D41733, the driver was modified such that,
when a user provided a mispelled option such as `-hel`, it would
suggest a valid option with a nearby edit distance: "did you mean
'-help'?".
Add these suggestions to invocations of `clang -cc1as` as well.
Test Plan: `check-clang`
Reviewers: v.g.vassilev, bruno
Reviewed By: v.g.vassilev
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D42001
llvm-svn: 322445
|
| |
|
|
| |
llvm-svn: 322444
|
| |
|
|
| |
llvm-svn: 322443
|
| |
|
|
|
|
|
|
| |
Oops, the waterfall tests with `-Werror -Wunused-variable`.
Differential Revision: https://reviews.llvm.org/D42028
llvm-svn: 322442
|
| |
|
|
|
|
| |
This reverts commit 7421eab7ccf2e14518f4526a084a5afc76ac9c6a.
llvm-svn: 322441
|
| |
|
|
|
|
|
| |
This should also fixe an unused varaible warning in the realeae
build.
llvm-svn: 322440
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This extends rL322327 to handle the pointer cast and should solve:
https://bugs.llvm.org/show_bug.cgi?id=35790
Name: or_eq_zero
%isnull = icmp eq i64* %p, null
%x = ptrtoint i64* %p to i64
%somebits = and i64 %x, %y
%somebits_are_zero = icmp eq i64 %somebits, 0
%or = or i1 %somebits_are_zero, %isnull
=>
%or = %somebits_are_zero
Name: and_ne_zero
%isnotnull = icmp ne i64* %p, null
%x = ptrtoint i64* %p to i64
%somebits = and i64 %x, %y
%somebits_are_not_zero = icmp ne i64 %somebits, 0
%and = and i1 %somebits_are_not_zero, %isnotnull
=>
%and = %somebits_are_not_zero
https://rise4fun.com/Alive/CQ3
llvm-svn: 322439
|
| |
|
|
| |
llvm-svn: 322438
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Some time ago, the sanitizers as of r315899 were imported into gcc mainline. This broke
bootstrap on Darwin 10 and 11, as reported in GCC PR sanitizer/82824
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82824) due to the unconditional use
of VM_MEMORY_OS_ALLOC_ONCE. This was only introduced in Darwin 13/Mac OS X 10.9.
The use of the macro was introduced in r300450.
I couldn't find any statement which Darwin versions are supposed to be supported by
LLVM, but the trivial patch to use the macro only if present allowed the gcc bootstrap
to finish.
So far, I haven't tried building llvm/compiler-rt on Darwin 11. Maybe the patch is
simple enough to go in nonetheless.
Committing on behalf of ro.
Reviewers: glider, fjricci, kcc, kuba, kubamracek, george.karpenkov
Reviewed By: fjricci
Subscribers: #sanitizers, zaks.anna, srhines, dberris, kubamracek, llvm-commits
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D39888
llvm-svn: 322437
|
| |
|
|
|
|
| |
As discussed in D41908
llvm-svn: 322436
|
| |
|
|
|
|
|
|
| |
Petr Hosek reported an external buildbot was failing on riscv32-toolchain.c,
seemingly as it set CLANG_DEFAULT_LINKER to lld. Address this by explicitly
setting -fuse-ld=ld in the tests.
llvm-svn: 322435
|
| |
|
|
|
|
| |
Improve coverage of D41811
llvm-svn: 322434
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the source file name for a compiland
Summary:
This commit is a combination of the following changes:
- Cache PDB's global scope (executable) in SymbolFilePDB
- Change naming of `cu` to `compiland` which is PDB specific
- Change ParseCompileUnitForSymIndex to ParseCompileUnitForUID.
Prefer using a common name `UID` instead of PDB's `System Index`
Adding one more argument `index` to this method, which is used to
specify the index of the compile unit in a cached compile unit array
- Add GetPDBCompilandByUID method to simply code
- Fix a bug in getting the source file name for a PDB compiland.
For some reason, PDBSymbolCompiland::getSourceFileName() could
return an empty name, so if that is true, we have to walk through all
source files of this compiland and determine the right source file
used to generate this compiland based on language indicated.
The previous implementation called PDBSession::findOneSourceFile
method to get its name for the compiland. This is not accurate since
the `one source file` found could be a header other than source file.
Reviewers: zturner, lldb-commits
Reviewed By: zturner
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D41428
llvm-svn: 322433
|
| |
|
|
|
|
|
|
| |
have AVX512 but not BWI.
This avoids having the result type stick around until lowering where we have to extend the setcc and insert a truncate. If we get the types converted early we can do more to optimize it.
llvm-svn: 322432
|
| |
|
|
|
|
|
|
|
| |
matching.
While here, fix up the myriad other ways in which Sema's two "can this handler
catch that exception?" implementations get things wrong and unify them.
llvm-svn: 322431
|
| |
|
|
| |
llvm-svn: 322430
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: Necessary to achieve consistent test results.
Reviewers: kcc, alekseyshl
Subscribers: kubamracek, llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D42023
llvm-svn: 322429
|
| |
|
|
|
|
|
|
| |
linker-initialized"
This reverts commit r322424: this broke the tsan lint check.
llvm-svn: 322428
|
| |
|
|
| |
llvm-svn: 322427
|
| |
|
|
| |
llvm-svn: 322426
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
*Mostly* NFC. Still updating the test though just for completeness.
This moves the hasAddressTaken check to MachineOutliner.cpp and replaces it
with a per-basic block test rather than a per-function test. The old test was
too conservative and was preventing functions in C programs from being
outlined even though they were safe to outline.
This was mostly a problem in C sources.
llvm-svn: 322425
|
| |
|
|
|
|
|
|
|
|
| |
It was always intended to be.
Patch By: mcgrathr
Differential Revision: https://reviews.llvm.org/D41513
llvm-svn: 322424
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D42013
llvm-svn: 322423
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: It is not necessary launching the build script with bash.
Reviewers: krytarowski
Reviewed By: krytarowski
Subscribers: llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D42008
llvm-svn: 322422
|
| |
|
|
|
|
|
|
|
|
|
|
| |
When a section placement (AT) command references the section itself,
the physical address of the section in the ELF header was calculated
incorrectly due to alignment happening right after the location
pointer's value was captured.
The problem was diagnosed and the first version of the patch written
by Erick Reyes.
llvm-svn: 322421
|
| |
|
|
| |
llvm-svn: 322420
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
A recent change
321556: AMDGPU: Remove mayLoad/hasSideEffects from MIMG stores
can allow the machine instruction scheduler to move an image store past
an image load using the same descriptor.
V2: Fixed by marking image ops as mayAlias and isAliased. This may be
overly conservative, and we may need to revisit.
V3: Reverted test change done on 321556.
Reviewers: arsenm, nhaehnle, dstuttard
Subscribers: llvm-commits, t-tye, yaxunl, wdng, kzhuravl
Differential Revision: https://reviews.llvm.org/D41969
llvm-svn: 322419
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
of a dSYM per-uuid plist that may be present (dsymutil does not
create this plist, it is only added after the fact by additional
tools) -- either the DBGBuildSourcePath + DBGSourcePath pair of
k-v entries which give us the build-time and debug-time remapping,
or the newer DBGSourcePathRemapping dictionary which may give us
multiple remappings.
I'm changing the order that we process these & add them to the
list of source remappings. If the DBGSourcePathRemapping dict
is present, it should be the first entries we will try.
<rdar://problem/36481989>
llvm-svn: 322418
|
| |
|
|
|
|
|
|
| |
The test was using "%clang++" which on Windows became "clang.exe++". Use %clangxx instead.
Reviewed by Paul Robinson
llvm-svn: 322417
|
| |
|
|
| |
llvm-svn: 322416
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
See https://bugs.llvm.org/show_bug.cgi?id=35533, and D40844
Things covered:
* Removing duplicate data segments (as determined by COMDATs emitted
by the frontend)
* Removing duplicate globals and functions in COMDATs
* Checking that each time a COMDAT is seen it has the same symbols
as at other times (ie it's a stronger check than simply giving all
the symbols in the COMDAT weak linkage)
Patch by Nicholas Wilson!
Differential Revision: https://reviews.llvm.org/D40845
llvm-svn: 322415
|