| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 292036
|
| |
|
|
| |
llvm-svn: 292035
|
| |
|
|
|
|
|
|
|
|
| |
This fixes some problems when building ClangDiagnostics.cpp on Visual Studio 2017 RC. As far as I understand, there was a change in the implementation of the constructor for std::vector with two iterator parameters, which in our case causes an attempt to dereference const Iterator objects. Since there was no overload for a const Iterator, the compile would fail.
Patch by Hugo Puhlmann!
Differential Revision: https://reviews.llvm.org/D28726
llvm-svn: 292034
|
| |
|
|
|
|
|
| |
Patch by Gonsolo.
Differential Revision: https://reviews.llvm.org/D28731
llvm-svn: 292031
|
| |
|
|
| |
llvm-svn: 292026
|
| |
|
|
| |
llvm-svn: 292025
|
| |
|
|
| |
llvm-svn: 292024
|
| |
|
|
|
|
| |
has landed
llvm-svn: 292023
|
| |
|
|
|
|
| |
VPMADCSWD act as VPADDD( VPMADDWD( x, y ), z ) - multiply+extend+hadd and add to v4i32 accumulator
llvm-svn: 292021
|
| |
|
|
|
|
| |
VPMACSDQH/VPMACSDQL act as VPADDQ( VPMULDQ( x, y ), z ) - multiply+extending either the odd/even 4i32 input elements and adding to v2i64 accumulator
llvm-svn: 292020
|
| |
|
|
|
|
| |
VPMACSWW/VPMACSDD act as add( mul( x, y ), z ) - ignoring any upper bits from both the multiply and add stages
llvm-svn: 292019
|
| |
|
|
|
|
|
|
| |
Tests showing missed opportunities to use XOP's integer fma instructions
Some of these are pretty awkward to match as they often have implicit sext/trunc stages but many just ignore overflow bits which makes things pretty straightforward.
llvm-svn: 292017
|
| |
|
|
| |
llvm-svn: 292014
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Correct handling of the following FileCheck options is implemented in
update_llc_test_checks.py and update_test_checks.py scripts:
1) -check-prefix (with a single dash)
2) -check-prefixes (with multiple prefixes)
Differential Revision: https://reviews.llvm.org/D28572
llvm-svn: 292008
|
| |
|
|
|
|
|
|
|
|
|
|
| |
instructions with blendm instructions when its beneficial.
Isel now selects masked move instructions for vselect instead of blendm. But sometimes it beneficial to register allocation to remove the tied register constraint by using blendm instructions.
This also picks up cases where the masked move was created due to a masked load intrinsic.
Differential Revision: https://reviews.llvm.org/D28454
llvm-svn: 292005
|
| |
|
|
|
|
|
|
|
|
| |
AVX512_128_SET0 expansion to make this possible.
We'll now expand AVX512_128_SET0 to an EVEX VXORD if VLX available. Or if its not, but register allocation has selected a non-extended register we will use VEX VXORPS. And if its an extended register without VLX we'll use a 512-bit XOR. Do the same for AVX512_FsFLD0SS/SD.
This makes it possible for the register allocator to have all 32 registers available to work with.
llvm-svn: 292004
|
| |
|
|
|
|
|
|
| |
This fallthrough if other cases are added between fabs and default
could cause fabs to fall to the next case resulting in a bug.
Better getting rid of it immediately just to be sure.
llvm-svn: 292003
|
| |
|
|
| |
llvm-svn: 291999
|
| |
|
|
|
|
| |
second loop.
llvm-svn: 291996
|
| |
|
|
|
|
|
|
| |
Also add 32-bit mode command lines to the test case that exercises this just to make sure we sanely handle the 64-bit immediate there.
This fixes a undefined sanitizer failure from r291888.
llvm-svn: 291994
|
| |
|
|
| |
llvm-svn: 291985
|
| |
|
|
|
|
| |
warnings; other minor fixes (NFC).
llvm-svn: 291983
|
| |
|
|
|
|
|
|
|
|
| |
extractProfTotalWeight checks if the profile type is sample profile, but
before that we have to ensure that summary is available. Also expanded
the unittest to test the case where there is no summar
Differential Revision: https://reviews.llvm.org/D28708
llvm-svn: 291982
|
| |
|
|
| |
llvm-svn: 291981
|
| |
|
|
| |
llvm-svn: 291980
|
| |
|
|
| |
llvm-svn: 291979
|
| |
|
|
|
|
|
|
|
|
| |
When GlobalISel is configured to abort rather than fallback the only
thing that resetting the machine function does is make things harder
to debug. If we ever get to this point in the abort configuration it
indicates that we've already hit a bug, so this changes the behaviour
to abort instead.
llvm-svn: 291977
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Allows LLVM to optimize sequences like the following:
%add = add nuw i32 %x, 1
%cmp = icmp ugt i32 %add, %y
Into:
%cmp = icmp uge i32 %x, %y
Previously, only signed comparisons were being handled.
Decrements could also be handled, but 'sub nuw %x, 1' is currently canonicalized to
'add %x, -1' in InstCombineAddSub, losing the nuw flag. Removing that canonicalization
seems like it might have far-reaching ramifications so I kept this simple for now.
Patch by Matti Niemenmaa!
Differential Revision: https://reviews.llvm.org/D24700
llvm-svn: 291975
|
| |
|
|
|
|
|
|
| |
Correctly populating Machine PHIs relies on knowing exactly how the IR level
CFG was lowered to MachineIR. This needs to be tracked by any translation
phases that meddle (currently only SwitchInst handling).
llvm-svn: 291973
|
| |
|
|
| |
llvm-svn: 291972
|
| |
|
|
| |
llvm-svn: 291970
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
dominating leader. Fixes PR 31613.
Summary:
This is a testcase where phi node cycling happens, and because we do
not order the leaders by domination or anything similar, the leader
keeps changing.
Using std::set for the members is too expensive, and we actually don't
need them sorted all the time, only at leader changes.
We could keep both a set and a vector, and keep them mostly sorted and
resort as necessary, or use a set and a fibheap, but all of this seems
premature.
After running some statistics, we are able to avoid the vast majority
of sorting by keeping a "next leader" field. Most congruence classes only have
leader changes once or twice during GVN.
Reviewers: davide
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D28594
llvm-svn: 291968
|
| |
|
|
|
|
|
|
|
|
| |
a llvm::ArrayRef<dwarf::Attribute>.
This allows us efficiently look for more than one attribute, something that is quite common in DWARF consumption.
Differential Revision: https://reviews.llvm.org/D28704
llvm-svn: 291967
|
| |
|
|
|
|
|
|
|
| |
The catchswitch instruction cannot be split, don't bother trying to
rewrite it.
This fixes PR31627.
llvm-svn: 291966
|
| |
|
|
|
|
| |
It used two attribute lookups when only one was needed.
llvm-svn: 291965
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Removed all DWARFDie::getAttributeValueAs*() calls.
Renamed:
Optional<DWARFFormValue> DWARFDie::getAttributeValue(dwarf::Attribute);
To:
Optional<DWARFFormValue> DWARFDie::find(dwarf::Attribute);
Added:
Optional<DWARFFormValue> DWARFDie::findRecursively(dwarf::Attribute);
All decoding of Optional<DWARFFormValue> values are now done using the dwarf::to*() functions from DWARFFormValue.h:
Old code:
auto DeclLine = DWARFDie.getAttributeValueAsSignedConstant(DW_AT_decl_line).getValueOr(0);
New code:
auto DeclLine = toUnsigned(DWARFDie.find(DW_AT_decl_line), 0);
This composition helps us since we can now easily do:
auto DeclLine = toUnsigned(DWARFDie.findRecursively(DW_AT_decl_line), 0);
This allows us to easily find attribute values in the current DIE only (the first new code above) or in any DW_AT_abstract_origin or DW_AT_specification Dies using the line above. Note that the code line length is shorter and more concise.
Differential Revision: https://reviews.llvm.org/D28581
llvm-svn: 291959
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The LLVM coding standards recommend "using" values that are only
needed by asserts:
http://llvm.org/docs/CodingStandards.html#assert-liberally
Without this change, LLVM cannot bootstrap with -Werror as the second
stage fails with this new warning:
https://reviews.llvm.org/rL291905
See also the previous fixes:
https://reviews.llvm.org/rL291916
https://reviews.llvm.org/rL291939
https://reviews.llvm.org/rL291940
https://reviews.llvm.org/rL291941
Reviewers: rsmith
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D28695
llvm-svn: 291957
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Only scalar half-precision operations are supported at the moment.
- Adds general support for 'half' type in NVPTX.
- fp16 math operations are supported on sm_53+ GPUs only
(can be disabled with --nvptx-no-f16-math).
- Type conversions to/from fp16 are supported on all GPU variants.
- On GPU variants that do not have full fp16 support (or if it's disabled),
fp16 operations are promoted to fp32 and results are converted back
to fp16 for storage.
Differential Revision: https://reviews.llvm.org/D28540
llvm-svn: 291956
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D28496
llvm-svn: 291954
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D28687
llvm-svn: 291948
|
| |
|
|
|
|
|
|
|
|
|
| |
reserved physreg in RegisterCoalescer.
Previously, we only checked for clobbers when merging into a READ of
the physreg, but not when merging from a WRITE to the physreg.
Differential Revision: https://reviews.llvm.org/D28527
llvm-svn: 291942
|
| |
|
|
| |
llvm-svn: 291937
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
allowed.
Previously we'd always lower @llvm.{sin,cos}.f32 to {sin.cos}.approx.f32
instruction even when unsafe FP math was not allowed.
Clang-generated IR is not affected by this as it uses precise sin/cos
from CUDA's libdevice when unsafe math is disabled.
Differential Revision: https://reviews.llvm.org/D28619
llvm-svn: 291936
|
| |
|
|
| |
llvm-svn: 291934
|
| |
|
|
|
|
|
|
|
|
| |
- For a loop body with VERY complicated exit condition evaluation, constant
evolving may run out of stack on platforms such as Windows. Need to limit the
recursion depth.
Differential Revision: https://reviews.llvm.org/D28629
llvm-svn: 291927
|
| |
|
|
| |
llvm-svn: 291926
|
| |
|
|
|
|
| |
This lowers to SHUFPD if the input is zeroinitializer but not with a demanded elts optimized build vector.
llvm-svn: 291924
|
| |
|
|
| |
llvm-svn: 291923
|
| |
|
|
| |
llvm-svn: 291920
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
libstdc++ has some undefined behavior in bits/stl_tree.h that
has recently became excercised by some of the LLVM code.
Given that fixing libstdc++ will take years, adding the file
into a blacklist to fix bots seems like a necessity.
Reviewers: vitalybuka
Subscribers: llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D28686
llvm-svn: 291918
|