This patch moves IntegerPolyhedron::reset to FlatAffineConstraints::reset. This
function is not required in IntegerPolyhedron and creates ambiguity while
shifting implementations to IntegerRelation.

This patch is part of a series of patches to introduce relations in Presburger
library.

Reviewed By: arjunp

Differential Revision: https://reviews.llvm.org/D120628

This is the SDAG equivalent of an instcombine transform added with:
fd807601

This is another step towards solving #49541 and part of an alternative
set of more general transforms than what is proposed in D111530.

https://alive2.llvm.org/ce/z/ToxaE8

The tests are adapted from a similar file for instcombine:
fd807601

For i16/32/64 vectors, if the upper bits are known to be zero, then we can try to truncate to vXi8 (if its worth it) and perform this as a PSADBW to add+zext each v4i8 subvector to a i64 sum, which we can then reduce together.

This addresses some of the PR42674 test cases where the source data was vXi8 but had been extended to match a wider unsigned integer accumulator.

Differential Revision: https://reviews.llvm.org/D120193

LOGIC (LOGIC (SH X0, Y), Z), (SH X1, Y) --> LOGIC (SH (LOGIC X0, X1), Y), Z

https://alive2.llvm.org/ce/z/QmR9rR

This is a reassociation + factoring fold. The common shift operation is moved
after a bitwise logic op on 2 input operands.
We get simpler cases of these patterns in IR, but I suspect we would miss all
of these exact tests in IR too. We also handle the simpler form of this plus
several other folds in DAGCombiner::hoistLogicOpWithSameOpcodeHands().

This is a partial implementation of a transform suggested in D111530
(only handles 'or' bitwise logic as a first step - need to stamp out more
tests for other opcodes).
Several of the same tests added for D111530 are altered here (but not
fully optimized). I'm not sure yet if this would help/hinder that patch,
but this should be an improvement for all tests added with ecf606cb
since it removes a shift operation in those examples.

Differential Revision: https://reviews.llvm.org/D120516

This reverts commit 7fb39fb6 as clang buildbots failed.

opt::setDefaultImpl() is changed to set the option value to the option
type's default if the Default field is not set. This results in option
value reset by Option::reset() or ResetAllOptionOccurrences() even if
the cl::init() is not specified.

Example:
  StackOption<std::string> Str("str"); // No cl::init().
  Str = "some value";
  cl::ResetAllOptionOccurrences();
  EXPECT_EQ("", Str); // The Str is reset.

Reviewed By: lattner
Differential Revision: https://reviews.llvm.org/D115433

This can be used to explicitly model VPValues that depend on SCEV
expansion, like the step for inductions.

Reviewed By: Ayal

Differential Revision: https://reviews.llvm.org/D116288

[lldb] BreakpointOptions::CommandData::CreateFromStructuredData - remove dead code + variable. NFCI.

The found_something bool is only ever read after it has always been set to true.

Looks to be a leftover debugging variable.

Fixes static analyzer warning: https://llvm.org/reports/scan-build/report-BreakpointOptions.cpp-CreateFromStructuredData-8-4055b9.html#EndPath

As reported on D120192

This is a small cache to avoid having to check both Exports and
Imports.

Differential Revision: https://reviews.llvm.org/D118589

Remove redundant isVALU call added in D120202.

This ports D95985 for ELF relocatable object files to BitcodeFile.

The change fixes treatment of constrained compare intrinsics if
compared values are of vector type.

Differential revision: https://reviews.llvm.org/D110322

The function has already been dereferenced the Var pointer

While here, fix an ugliness:
  auto foo()->auto { return 42; }
This (silly) code gains a "-> int" hint. While correct and useful, it renders as
  auto foo()->int->auto { return 42; }
which is confusing enough to do more harm than good I think.

Differential Revision: https://reviews.llvm.org/D120416

Why put "InMacros" in the name? We test other things to, and I will add
more, withut macros.

Also all our tests are regression tests.

Differential Revision: https://reviews.llvm.org/D120401

All "calls" have a semi, as they should, remove the one from the macro.

Differential Revision: https://reviews.llvm.org/D120359

This is both less code and faster since it doesn't have to expand all
the sub & superreg sets. NFCI.

PDL currently doesn't support result values from constraints, meaning we need
to error out until this is actually supported to avoid crashes.

Differential Revision: https://reviews.llvm.org/D119782

This commits adds a C++ generator to PDLL that generates wrapper PDL patterns
directly usable in C++ code, and also generates the definitions of native constraints/rewrites
that have code bodies specified in PDLL. This generator is effectively the PDLL equivalent of
the current DRR generator, and will allow easy replacement of DRR patterns with PDLL patterns.
A followup will start to utilize this for end-to-end integration testing and show case how to
use this as a drop-in replacement for DRR tablegen usage.

Differential Revision: https://reviews.llvm.org/D119781

If the operand list or result list of an operation expression is not specified, we interpret
this as meaning that the operands/results are "unconstraint" (i.e. "could be anything").
We currently don't properly handle differentiating this case from the case of
"no operands/results". This commit adds the insertion of implicit value/type range
variables when these lists are unspecified. This allows for adding proper support
for when zero operands or results are expected.

Differential Revision: https://reviews.llvm.org/D119780

This commits starts to plumb PDLL down into MLIR and adds an initial
PDL generator. After this commit, we will have conceptually support
end-to-end execution of PDLL. Followups will add CPP generation to
match the current DRR setup, and begin to add various end-to-end
tests to test PDLL execution.

Differential Revision: https://reviews.llvm.org/D119779

A merge conflict in D106124 accidentally reverted this part of
b82683b2/D110794.

> Even if these comments have a benefit in .h files (for editors that
> care about language but can't be configured to treat .h as C++ code),
> they certainly have no benefit for files with the .cpp extension.

9f5f0847 (D119770) made this test pass in the Windows configuration too,
but didn't update the XFAIL accordingly.

Differential Revision: https://reviews.llvm.org/D120611

This patch removes a redundant check in hasConsistentState which is always true
after introduction of PresburgerSpace.

Reviewed By: arjunp

Differential Revision: https://reviews.llvm.org/D120615

This patch adds a new transform to remove dead recipes. For now, it only
removes dead recipes in the header, to keep the number tests that require
updating manageable. Future patches will extend this to remove dead
recipes across the whole plan.

Reviewed By: Ayal

Differential Revision: https://reviews.llvm.org/D118051

b85f97bc missed one file.

With this, all files listed in libcxx/include/CMakeLists.txt are
listed in this BUILD.gn file again.

410d4492 only hit half the added files.

Ports 87a82490 in a way. Has the effect of enabling warnings
when building libcxx itself, but more importantly this is required
after 5aaefa51 to not get build errors when building libcxx itself.

Adds another interesting test for D118051.

See post-commit discussion on https://reviews.llvm.org/D120305.
This change breaks the clang-ppc64le-rhel buildbot, though
there is suspicion that it's an issue with the bot. The change
also had a larger than expected impact on compile-time and
code-size.

This reverts commit 3c4ed026
and some followup changes.

This patch moves identifier kind specific insert/append functions like
`insertDimId`, `appendSymbolId`, etc. from IntegerPolyhedron to
FlatAffineConstraints.

This change allows for a smoother transition to IntegerRelation.

This change is part of a series of patches to introduce Relations in Presburger
library.

Reviewed By: arjunp

Differential Revision: https://reviews.llvm.org/D120576

For TemplateSpecializationType, we were checking the node's newness
twice, so it always failed the second test.

Fixes https://github.com/clangd/clangd/issues/1036