| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
blocks. NFC
These were added as part of the refactoring for prefer vector width. At the time I thought the hasAVX512 here would be replaced with "allow 512 bit vectors" so that it would read "allow 512 bit vectors OR VLX". But now the plan is to only give the option of disabling 512 bit vectors when VLX is enabled. So we don't need this qualification at all
llvm-svn: 324831
|
|
|
|
| |
llvm-svn: 324830
|
|
|
|
|
|
| |
As discussed on D43014, we need the ability to flip SMIN/SMAX to (legal) UMIN/UMAX
llvm-svn: 324829
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
return vXi1 mask. Make bitcasts to scalar explicit in IR
Summary: This is the clang equivalent of r324827
Reviewers: zvi, delena, RKSimon, spatel
Reviewed By: RKSimon
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D43143
llvm-svn: 324828
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
vXi1 mask type to be closer to an fcmp.
Summary:
This patch changes the signature of the avx512 packed fp compare intrinsics to return a vXi1 vector and no longer take a mask as input. The casts to scalar type will now need to be explicit in the IR. The masking node will now be an explicit and in the IR.
This makes the intrinsic look much more similar to an fcmp instruction that we wish we could use for these but can't. We already use icmp instructions for integer compares.
Previously the lowering step of isel would turn the intrinsic into an X86 specific ISD node and a emit the masking nodes as well as some bitcasts. This means DAG combines can't see the vXi1 type until somewhat late, making it more difficult to combine out gpr<->mask transition sequences. By exposing the vXi1 type explicitly in the IR and initial SelectionDAG we give earlier DAG combines and even InstCombine the chance to see it and optimize it.
This should make any issues with gpr<->mask sequences the same between integer and fp. Meaning we only have to fix them once.
Reviewers: spatel, delena, RKSimon, zvi
Reviewed By: RKSimon
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D43137
llvm-svn: 324827
|
|
|
|
|
|
| |
As discussed on D43014, we need the ability to flip UMIN/UMAX to (legal) SMIN/SMAX
llvm-svn: 324826
|
|
|
|
|
|
| |
Includes adding m_NonNegative constant pattern matcher
llvm-svn: 324825
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This test would fail if the python path had spaces. Add a quote around the path to fix this problem and update some test values changed by the addition of quotes around the path.
Tested on Windows and Linux with Python 3.x
Reviewers: zturner, llvm-commits
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D43164
llvm-svn: 324824
|
|
|
|
|
|
| |
Until Skylake, most hardware could only issue a PMULLD op every other cycle
llvm-svn: 324823
|
|
|
|
|
|
|
|
|
|
| |
(v4i1 (setcc (v4f32)))
Undef VLX, getSetCCResultType returns v2i1/v4i1 for v2f32/v4f32 so default type legalization will end up changing the setcc result type back to vXi1 if it had been extended. The resulting extend gets messed up further by type legalization and is difficult to recombine back to (v4i32 (setcc (v4f32))) after legalization.
I went ahead and enabled this for SSE2 and later since its always the result we want and this helps type legalization get there in less steps.
llvm-svn: 324822
|
|
|
|
| |
llvm-svn: 324821
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
before type legalization.
This prevents extends of masks being introduced during lowering where it become difficult to combine them out.
There are a few oddities in here.
We sometimes concatenate two k-registers produced by two compares, sign_extend the combined pair, then extract two halves. This worked better previously because the sign_extend wasn't created until after the fp_to_sint was split which led to a split sign_extend being created.
We probably also need to custom type legalize (v2i32 (sext v2i1)) via widening.
llvm-svn: 324820
|
|
|
|
|
|
|
|
|
|
| |
upcoming patch.
The update script sometimes has trouble when there are check-prefixes representing every possible combination of feature flags. I have a patch where the update script was generating something that didn't pass lit.
This patch just removes some check-prefixes and expands out some of the checks to workaround this.
llvm-svn: 324819
|
|
|
|
|
|
| |
Ensure the scalar is correctly splatted to all lanes
llvm-svn: 324818
|
|
|
|
|
|
|
| |
D43141 proposes to correct undef folding in the DAG,
and this test would not survive that change.
llvm-svn: 324817
|
|
|
|
|
|
|
| |
D43141 proposes to correct undef folding in the DAG,
and this test would not survive that change.
llvm-svn: 324816
|
|
|
|
| |
llvm-svn: 324815
|
|
|
|
|
|
|
| |
D43141 proposes to correct undef folding in the DAG,
and this test would not survive that change.
llvm-svn: 324814
|
|
|
|
| |
llvm-svn: 324813
|
|
|
|
| |
llvm-svn: 324812
|
|
|
|
|
|
| |
Noted by David CARLIER.
llvm-svn: 324811
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
textdomain is a part of -lintl on BSDs. In GLIBC it's in libc.
We assume that -lintl will need to be rebuilt with sanitizers
in order to sanitize programs using its features.
This is a proper continuation of D41013.
The original patch has been reverted (adding -lintl).
llvm-svn: 324810
|
|
|
|
| |
llvm-svn: 324809
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds a base-class called TemplateInstantiationObserver which gets
notified whenever a template instantiation is entered or exited during
semantic analysis. This is a base class used to implement the template
profiling and debugging tool called
Templight (https://github.com/mikael-s-persson/templight).
The patch also makes a few more changes:
* ActiveTemplateInstantiation class is moved out of the Sema class (so it can be used with inclusion of Sema.h).
* CreateFrontendAction function in front-end utilities is given external linkage (not longer a hidden static function).
* TemplateInstObserverChain data member added to Sema class to hold the list of template-inst observers.
* Notifications to the template-inst observer are added at the key places where templates are instantiated.
Patch by: Abel Sinkovics!
Differential Revision: https://reviews.llvm.org/D5767
llvm-svn: 324808
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: some compiler (msvc) treats Buffer.Buffer as constructor and refuse to compile. NFC
Authored by comicfans44.
Reviewers: rnk, dberris
Reviewed By: dberris
Subscribers: llvm-commits
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D40346
llvm-svn: 324807
|
|
|
|
|
|
| |
Strangely the code was already present, just the setOperationAction wasn't being called without VLX.
llvm-svn: 324806
|
|
|
|
|
|
|
|
|
|
| |
extend and a shift.
This avoids a constant pool load to create 1.
The int->float are showing converts to mask and back. We probably need to widen inputs to sint_to_fp/uint_to_fp before type legalization.
llvm-svn: 324805
|
|
|
|
|
|
|
|
| |
then masking. A later DAG combine will convert to a shift.
This helps to avoid a constant pool load needed to zero extend from the mask.
llvm-svn: 324804
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This revision refactors 1. parser 2. CHECK line adder of utils/update_{,llc_}test_checks.py
so that thir functionality can be re-used by other utility scripts (e.g. D42712)
Reviewers: asb, craig.topper, RKSimon, echristo
Subscribers: llvm-commits, spatel
Differential Revision: https://reviews.llvm.org/D42805
llvm-svn: 324803
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Massive false positives were known to be caused by continuing the analysis
after a destructor with a noreturn attribute has been executed in the program
but not modeled in the analyzer due to being missing in the CFG.
Now that work is being done on enabling the modeling of temporary constructors
and destructors in the CFG, we need to make sure that the heuristic that
suppresses these false positives keeps working when such modeling is disabled.
In particular, different code paths open up when the corresponding constructor
is being inlined during analysis.
Differential Revision: https://reviews.llvm.org/D42779
llvm-svn: 324802
|
|
|
|
|
|
|
|
|
|
| |
It was introduced when two -analyzer-config options were added almost
simultaneously in r324793 and r324668 and the option count was not
rebased correctly in the tests.
Fixes the buildbots.
llvm-svn: 324801
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The analyzer was relying on peeking the next CFG element during analysis
whenever it was trying to figure out what object is being constructed
by a given constructor. This information is now available in the current CFG
element in all cases that were previously supported by the analyzer,
so no complicated lookahead is necessary anymore.
No functional change intended - the context in the CFG should for now be
available if and only if it was previously discoverable via CFG lookahead.
Differential Revision: https://reviews.llvm.org/D42721
llvm-svn: 324800
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Patch from ngolovliov@gmail.com
Reviewed as: https://reviews.llvm.org/D42344
As described in llvm.org/PR30959, the current
implementation of std::{map, key}::{count, equal_range} in libcxx is
non-conforming. Quoting the C++14 standard [associative.reqmts]p3
> The phrase “equivalence of keys” means the equivalence relation imposed by
> the comparison and not the operator== on keys. That is, two keys k1 and k2 are
> considered to be equivalent if for the comparison object comp,
> comp(k1, k2) == false && comp(k2, k1) == false.
In the same section, the requirements table states the following:
> a.equal_range(k) equivalent to make_pair(a.lower_bound(k), a.upper_bound(k))
> a.count(k) returns the number of elements with key equivalent to k
The behaviour of libstdc++ seems to conform to the standard here.
llvm-svn: 324799
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now that we make it possible to query the CFG constructor element to find
information about the construction site, possible cleanup work represented by
ExprWithCleanups should not prevent us from providing this information.
This allows us to have a correct construction context for variables initialized
"by value" via elidable copy-constructors, such as 'i' in
iterator i = vector.begin();
Differential Revision: https://reviews.llvm.org/D42719
llvm-svn: 324798
|
|
|
|
|
|
|
| |
All uses conservatively assume in early exit case that it will be a
predecessor. Changing default removes checking code in all uses.
llvm-svn: 324797
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CFG elements for constructors of fields and base classes that are being
initialized before the body of the whole-class constructor starts can now be
queried to discover that they're indeed participating in initialization of their
respective fields or bases before the whole-class constructor kicks in.
CFG construction contexts are now capable of representing CXXCtorInitializer
triggers, which aren't considered to be statements in the Clang AST.
Differential Revision: https://reviews.llvm.org/D42700
llvm-svn: 324796
|
|
|
|
|
|
|
|
|
| |
arch incompat with spec in file so it's rejected and the test fails.
will look into this later, will be a test case issue not a test issue;
test case may only be valid when lldb is built for/running on an x86_64
system.
llvm-svn: 324795
|
|
|
|
|
|
|
|
|
| |
Constructors of simple variables now can be queried to discover that they're
constructing into simple variables.
Differential Revision: https://reviews.llvm.org/D42699
llvm-svn: 324794
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D43131
llvm-svn: 324793
|
|
|
|
|
|
| |
target.xml packet if it is included.
llvm-svn: 324792
|
|
|
|
|
|
| |
insert_subvectors and extract_subvector sequences to remove extra zeroing.wq
llvm-svn: 324791
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This expression may or may not be evaluated in compile time, so tracking the
result symbol is of potential interest. However, run-time offsetof is not yet
supported by the analyzer, so for now this callback is only there to assist
future implementation.
Patch by Henry Wong!
Differential Revision: https://reviews.llvm.org/D42300
llvm-svn: 324790
|
|
|
|
|
|
|
|
|
|
|
| |
This builtin is evaluated in compile time. But in the analyzer we don't yet
automagically evaluate all calls that can be evaluated in compile time.
Patch by Felix Kostenzer!
Differential Revision: https://reviews.llvm.org/D42745
llvm-svn: 324789
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
same timer feasible
Currently, each LLVM timer can be only printed once, as the act of
printing clears the timer.
Moreover, the current printing mechanism implicitly assumes that the
timer is stopped -- and prints zero otherwise.
This patch relaxes this assumption and makes printing statistics
multiple time a possibility.
Differential Revision: https://reviews.llvm.org/D43136
llvm-svn: 324788
|
|
|
|
|
|
|
|
| |
One test uses diff, the other tries to change the PATH which doesn't
seem to work well ('not' is no longer accessible/found after the PATH is
changed - I think $PATH isn't expanded when setting PATH).
llvm-svn: 324787
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
If -pass-remarks=loop-vectorize, atomic ops will be seen by
analyzeInterleaving(), even though canVectorizeMemory() == false. This
is because we are requesting extra analysis instead of bailing out.
In such a case, we end up with a Group in both Load- and StoreGroups,
and then we'll try to access freed memory when traversing LoadGroups after having had released the Group when iterating over StoreGroups.
The fix is to include mayWriteToMemory() when validating that two
instructions are the same kind of memory operation.
Reviewers: mssimpso, davidxl
Reviewed By: davidxl
Subscribers: hsaito, fhahn, llvm-commits
Differential Revision: https://reviews.llvm.org/D43064
llvm-svn: 324786
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D43133
llvm-svn: 324785
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This change is part of step five in the series of changes to remove alignment argument from
memcpy/memmove/memset in favour of alignment attributes. In particular, this changes the
Hexagon LoopIdiom pass to cease using the old IRBuilder createMemCpy/createMemMove
single-alignment APIs in favour of the new API that allows setting source and
destination alignments independently.
Steps:
Step 1) Remove alignment parameter and create alignment parameter attributes for
memcpy/memmove/memset. ( rL322965, rC322964, rL322963 )
Step 2) Expand the IRBuilder API to allow creation of memcpy/memmove with differing
source and dest alignments. ( rL323597 )
Step 3) Update Clang to use the new IRBuilder API. ( rC323617 )
Step 4) Update Polly to use the new IRBuilder API. ( rL323618 )
Step 5) Update LLVM passes that create memcpy/memmove calls to use the new IRBuilder API,
and those that use use MemIntrinsicInst::[get|set]Alignment() to use [get|set]DestAlignment()
and [get|set]SourceAlignment() instead. ( rL323886, rL323891, rL324148, rL324273, rL324278,
rL324384, rL324395, rL324402, rL324626, rL324642, rL324653, rL324654, rL324773, rL324774,
rL324781 )
Step 6) Remove the single-alignment IRBuilder API for memcpy/memmove, and the
MemIntrinsicInst::[get|set]Alignment() methods.
Reference
http://lists.llvm.org/pipermail/llvm-dev/2015-August/089384.html
http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20151109/312083.html
llvm-svn: 324784
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the output file is not specified make the modifications in-place
(like binutils objcopy does). In particular, this fixes
the behavior of Clang -gsplit-dwarf (if Clang is configured to use llvm-objcopy),
previously it was creating .dwo files, but still leaving *dwo* sections in
the original binary.
Test plan: make check-all
Differential revision: https://reviews.llvm.org/D42873
llvm-svn: 324783
|
|
|
|
|
|
|
|
| |
filling upper elements with zero. Replace with insert_subvector.
There's still some extra kshifts in one of the modified test cases here, but hopefully that's only a DAG combine away.
llvm-svn: 324782
|