Recurse instead of returning on the first found optimization. Also, return early in the caller
instead of continuing because that allows another round of simplification before we might
potentially lose undef information from a shuffle mask by eliminating the shuffle.
As noted in the review, we could probably do better and be more efficient by moving all of
demanded elements into a separate pass, but this is yet another quick fix to instcombine.
Differential Revision: https://reviews.llvm.org/D37236
llvm-svn: 312248
Summary:
Hopefully this also clarifies exactly when and why we're rewriting
certiain S_LOCALs using reference types: We're using the reference type
to stand in for a zero-offset load.
Reviewers: inglorion
Subscribers: llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D37309
llvm-svn: 312247
The buildbots have shown that -Wstrict-prototypes behaves differently in GCC
and Clang so we should keep it disabled until Clang follows GCC's behaviour
llvm-svn: 312246
Extract the ARC migration tool flag handling into its own function.
This simplifies the flow of the clang frontend command line construction
function. NFC.
llvm-svn: 312244
Clang 5 supports -Wstrict-prototypes. We should use it to catch any C
declarations that declare a non-prototype function.
rdar://33705313
Differential Revision: https://reviews.llvm.org/D36669
llvm-svn: 312240
This is useful when we face certain intrinsics such as `llvm.exp.*`
which cannot be lowered by the NVPTX backend while other intrinsics can.
So, we would need to keep blacklists of intrinsics that cannot be
handled by the NVPTX backend. It is much simpler to try and promote
all intrinsics to libdevice versions.
This patch makes function/intrinsic very uniform, and will always try to use
a libdevice version if it exists.
Differential Revision: https://reviews.llvm.org/D37056
llvm-svn: 312239
Summary:
This patch enables the following:
1) Regex based Instruction itineraries for integer instructions.
2) The instructions are grouped as per the nature of the instructions
(move, arithmetic, logic, Misc, Control Transfer).
3) FP instructions and their itineraries are added which includes values
for SSE4A, BMI, BMI2 and SHA instructions.
Patch by Ganesh Gopalasubramanian
Reviewers: RKSimon, craig.topper
Subscribers: vprasad, shivaram, ddibyend, andreadb, javed.absar, llvm-commits
Differential Revision: https://reviews.llvm.org/D36617
llvm-svn: 312237
The CodingStandards section on avoiding the re-evaluation of end() hasn't been
updated since range-based for loops were adopted in the LLVM codebase. This
patch adds a very brief section that documents how range-based for loops
should be used wherever possible. It also moves example code in
CodingStandards to use range-based for loops and auto when appropriate.
Differential Revision: https://reviews.llvm.org/D37264
llvm-svn: 312236
We are starting to use data flow tracing in kernel.
The interface is not subject to change anymore.
Reviewed in https://reviews.llvm.org/D37303
llvm-svn: 312232
New instructions are added to AArch32 and AArch64 to aid
floating-point multiplication and addition of complex numbers,
where the complex numbers are packed in a vector register as a
pair of elements. The Imaginary part of the number is placed in the
more significant element, and the Real part of the number is placed
in the less significant element.
Differential Revision: https://reviews.llvm.org/D36792
llvm-svn: 312228
Summary: Add a -name-whitelist option, which behaves in the same way as -name, but it reads in multiple function names from the given input file(s).
Reviewers: vsk
Reviewed By: vsk
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D37111
llvm-svn: 312227
Replace the UsePostRAScheduler SubtargetFeature with
DisablePostRAScheduler, which is then used by Swift and Cyclone.
This patch maintains enabling PostRA scheduling for other Thumb2
capable cores and/or for functions which are being compiled in Arm
mode.
Differential Revision: https://reviews.llvm.org/D37055
llvm-svn: 312226
The IDSAR6 system register has been introduced to identify the
v8.3-a Javascript data type conversion and v8.2-a dot product
support.
Differential Revision: https://reviews.llvm.org/D37068
llvm-svn: 312225
This fixes cases where dynamic classes produced RTTI data with
external linkage, producing linker errors about duplicate symbols.
This touches code close to what was changed in SVN r244266, but
this change doesn't break the tests added in that revision.
Differential revision: https://reviews.llvm.org/D37206
llvm-svn: 312224
This is similar to what was done for ARM in SVN r269574; the code
and the test are straight copypaste to the corresponding AArch64
code and test directory.
Differential revision: https://reviews.llvm.org/D37204
llvm-svn: 312223
Summary:
This patch aims at optimizing the CloneChecker for larger programs. Before this
patch we took around 102 seconds to analyze sqlite3 with a complexity value of
50. After this patch we now take 2.1 seconds to analyze sqlite3.
The biggest performance optimization is that we now put the constraint for group
size before the constraint for the complexity. The group size constraint is much
faster in comparison to the complexity constraint as it only does a simple
integer comparison. The complexity constraint on the other hand actually
traverses each Stmt and even checks the macro stack, so it is obviously not able
to handle larger amounts of incoming clones. The new order filters out all the
single-clone groups that the type II constraint generates in a faster way before
passing the fewer remaining clones to the complexity constraint. This reduced
runtime by around 95%.
The other change is that we also delay the verification part of the type II
clones back in the chain of constraints. This required to split up the
constraint into two parts - a verification and a hash constraint (which is also
making it more similar to the original design of the clone detection algorithm).
The reasoning for this is the same as before: The verification constraint has to
traverse many statements and shouldn't be at the start of the constraint chain.
However, as the type II hashing has to be the first step in our algorithm, we
have no other choice but split this constrain into two different ones. Now our
group size and complexity constrains filter out a chunk of the clones before
they reach the slow verification step, which reduces the runtime by around 8%.
I also kept the full type II constraint around - that now just calls it's two
sub-constraints - in case someone doesn't care about the performance benefits
of doing this.
Reviewers: NoQ
Reviewed By: NoQ
Subscribers: klimek, v.g.vassilev, xazax.hun, cfe-commits
Differential Revision: https://reviews.llvm.org/D34182
llvm-svn: 312222
Current implementation of parseLoopStructure interprets the latch comparison as a
comarison against `iv.next`. If the actual comparison is made against the `iv` current value
then the loop may be rejected, because this misinterpretation leads to incorrect evaluation
of the latch start value.
This patch teaches the IRCE to distinguish this kind of loops and perform the optimization
for them. Now we use `IndVarBase` variable which can be either next or current value of the
induction variable (previously we used `IndVarNext` which was always the value on next iteration).
Differential Revision: https://reviews.llvm.org/D36215
llvm-svn: 312221
Extend the -fmodule-file option to support the [<name>=]<file> value format.
If the name is omitted, then the old semantics is preserved (the module file
is loaded whether needed or not). If the name is specified, then the mapping
is treated as just another prebuilt module search mechanism, similar to
-fprebuilt-module-path, and the module file is only loaded if actually used
(e.g., via import). With one exception: this mapping also overrides module
file references embedded in other modules (which can be useful if module files
are moved/renamed as often happens during remote compilation).
This override semantics requires some extra work: we now store the module name
in addition to the file name in the serialized AST representation.
Reviewed By: rsmith
Differential Revision: https://reviews.llvm.org/D35020
llvm-svn: 312220
r312167 made it so that we emit Wdelete-non-virtual-dtor from delete statements
that are in system headers (e.g. std::unique_ptr). That works great on Linux
and macOS, but on Windows there are non-final classes that are defined in
system headers that have virtual methods but non-virtual destructors and yet
get deleted through a base class pointer (e.g. ATL::CAccessToken::CRevert). So
paddle back a bit and don't emit the warning if it's about a class defined in a
system header.
https://reviews.llvm.org/D37324
llvm-svn: 312216
Renaming as a preparation step to generalizing IRCE for comparison not only against
the next value of an indvar, but also against the current.
Differential Revision: https://reviews.llvm.org/D36509
llvm-svn: 312215
The adds code generation support for the previous commit.
This patch has been re-applied, after the memory issue in the previous patch
has been fixed.
llvm-svn: 312211
By using statement lists in the entry blocks of region statements, instruction
level analyses also work on region statements.
We currently only model the entry block of a region statements, as this is
sufficient for most transformations the known-passes currently execute. Modeling
instructions in the presence of control flow (e.g. infinite loops) is left
out to not increase code complexity too much. It can be added when good use
cases are found.
This change set is reapplied, after a memory corruption issue had been fixed.
llvm-svn: 312210
Summary:
xmlDoc needs to be released with xmlFreeDoc.
Reset root element before release to avoid release of CombinedRoot owned
by CombinedDoc,
Reviewers: ecbeckmann, rnk, zturner, ruiu
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D37321
llvm-svn: 312207
The majority of the time spent in the pass checking
for the register reads. Rather than searching all of
the defined registers for uses in each instruction,
use a set of defined registers and check the operands
of the instruction.
This process still is algorithmically not great,
but with the additional trick of skipping the analysis
for addresses with one use, this brings one slow
testcase into a reasonable range.
llvm-svn: 312206
Summary:
Before this patch, llvm-xray account will assume that thread stacks will
not be empty. Unfortunately there are cases where an instrumented
function will see a call to `fork()` which will cause the child process
to not see the start of the function, but only see the end of the
function. The tooling cannot assume that threads will always have
perfect stacks, and so we change it to support this reality.
Reviewers: dblaikie
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31870
llvm-svn: 312204
Summary:
Before this change we seemed to not be running the unit tests, and therefore we
set out to run them. In the process of making this happen we found a divergence
between the implementation and the tests.
This includes changes to both the CMake files as well as the implementation and
headers of the XRay runtime. We've also updated documentation on the changed
functions.
Reviewers: kpw, eizan
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D37290
llvm-svn: 312202
This moves the cmake configuration for fuzzers in LLVM to a new macro,
add_llvm_fuzzer. This will make it easier to keep things consistent
while implementing llvm.org/pr34314.
I've also made a couple of minor functional changes here:
- the fuzzers now use add_llvm_executable rather than add_llvm_tool.
This means they won't create install targets and stuff like that,
because those made little sense for these fuzzers.
- I've grouped these under "Fuzzers" rather than in with "Tools" for
people who build with IDEs.
llvm-svn: 312200
Sanjay Patel