Remove local (uniform) constant folding and rely on getNode() to perform it

Minor cleanup step toward adding non-uniform shift amount support

Fixes https://github.com/llvm/llvm-project/issues/55610.

Reviewed By: MyDeveloperDay

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

Amends 681c50c6 and hopefully fixes:

https://lab.llvm.org/buildbot/#/builders/109/builds/39347
https://lab.llvm.org/buildbot/#/builders/188/builds/14634
and others

Post-commit feedback on https://reviews.llvm.org/D122895 pointed out
that the diagnostic wording for some code was using "declaration" in a
confusing way, such as:

int foo(); // warning: a function declaration without a prototype is deprecated in all versions of C and is not supported in C2x

int foo(int arg) { // warning: a function declaration without a prototype is deprecated in all versions of C and is not supported in C2x
  return 5;
}

And that we had other minor issues with the diagnostics being somewhat
confusing.

This patch addresses the confusion by reworking the implementation to
be a bit more simple and a bit less chatty. Specifically, it changes
the warning and note diagnostics to be able to specify "declaration" or
"definition" as appropriate, and it changes the function merging logic
so that the function without a prototype is always what gets warned on,
and the function with a prototype is sometimes what gets noted.
Additionally, when diagnosing a K&R C definition that is preceded by a
function without a prototype, we don't note the prior declaration, we
warn on it because it will also be changing behavior in C2x.

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

Dependent patch adds UnarySymExpr, now I'd like to handle that for SMT
conversions like refutation.

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

Fixes https://github.com/llvm/llvm-project/issues/55241

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

This patch adds a new descendant to the SymExpr hierarchy. This way, now
we can assign constraints to symbolic unary expressions. Only the unary
minus and bitwise negation are handled.

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

Depends on D124758. That patch introduced serious regression in the run-time in
some special cases. This fixes that.

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

Resolves part of
https://github.com/llvm/llvm-project/issues/38652

Reviewed By: dp

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

This ensures that a deduced type like __auto_type matches the correct
association instead of matching all associations.

This addresses a regression from e4a42c5b

Fixes #55702

Prep work as I'm investigating some cases where TLI::convertSetCCLogicToBitwiseLogic should accept vectors.

Also fix directives not covered by D125604.

reapply 62a9b36f and fix module build
failue:
1: remove MachineCycleInfoWrapperPass in MachinePassRegistry.def
   MachineCycleInfoWrapperPass is a anylysis pass, should not be there.
2: move the definition for MachineCycleInfoPrinterPass to cpp file.

Otherwise, there are module conflicit for MachineCycleInfoWrapperPass
in MachinePassRegistry.def and MachineCycleAnalysis.h after
62a9b36f.

MachineCycle can handle irreducible loop. Natural loop
analysis (MachineLoop) can not return correct loop depth if
the loop is irreducible loop. And MachineSink is sensitive
to the loop depth, see MachineSinking::isProfitableToSinkTo().

This patch tries to use MachineCycle so that we can handle
irreducible loop better.

Reviewed By: sameerds, MatzeB

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

Reviewed By: MaskRay

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

The Transform dialect uses the side effect modeling mechanism to record the
effects of the transform ops on the mapping between Transform IR values and
Payload IR ops. Introduce a checker pass that warns if a Transform IR value is
used after it has been freed (consumed). This pass is mostly intended as a
debugging aid in addition to the verification/assertion mechanisms in the
transform interpreter. It reports all potential use-after-free situations.
The implementation makes a series of simplifying assumptions to be simple and
conservative. A more advanced implementation would rely on the data flow-like
analysis associated with a side-effect resource rather than a value, which is
currently not supported by the analysis infrastructure.

Reviewed By: springerm

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

Fixes failure seen when building without X86 backend:
https://lab.llvm.org/buildbot/#/builders/171/builds/15124

These shows that the cost of a @llvm.vscale is indeed 1, not 10.

Reviewed By: var-const, #libc

Spies: libcxx-commits, mgorny

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

When updating the branch instruction outside the loopduring non-trivial
 unswitching, always skip trivial selects and update the condition.

Otherwise we might create invalid IR, because the trivial select is
inside the loop, while the condition is outside the loop.

Fixes #55697.

We didn't implement RISCVELFStreamer::reset and cause some very strange
section output for attribute section...just reference D15950 to see how
ARM implement that.

Reviewed By: MaskRay

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

This reverts commit c274b6e5.

The x86_64 debian bot got a failure with this patch,
https://lab.llvm.org/buildbot#builders/68/builds/33078
where
SymbolFile/DWARF/x86/DW_TAG_variable-DW_AT_decl_file-DW_AT_abstract_origin-crosscu1.s
is crashing here -

 #2 0x0000000000425a9f SignalHandler(int) Signals.cpp:0:0
 #3 0x00007f57160e9140 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x14140)
 #4 0x00007f570d911e43 lldb_private::SourceManager::GetFile(lldb_private::FileSpec const&) crtstuff.c:0:0
 #5 0x00007f570d914270 lldb_private::SourceManager::DisplaySourceLinesWithLineNumbers(lldb_private::FileSpec const&, unsigned int, unsigned int, unsigned int, unsigned int, char const*, lldb_private::Stream*, lldb_private::SymbolContextList const*) crtstuff.c:0:0
 #6 0x00007f570da662c8 lldb_private::StackFrame::GetStatus(lldb_private::Stream&, bool, bool, bool, char const*) crtstuff.c:0:0

I don't get a failure here my mac, I'll review this method more
closely tomorrow.

When reading source path remappings out of a dSYM, lldb currently
does tilde expansion -- expanding the tilde-username and checking
that the destination pathname exists, for each dSYM with the path
remappings.  This cost happens during lldb's initial process launch
/ load, an especially perf-sensitive time.  Inside Apple, we have
dSYMs with source path remappings pointing to NFS directories where
these extra stats for every dSYM can be very expensive if the network
is slow.

This patch instead keeps the source path mapping in the original
tilde-username terms and does the tilde expansion when we need
to read a specific source file from one of the modules.  We'll
be stat'ing all of those inodes to load the source file anyway,
so the fact that we do the tilde expansion on every source file
we load, it doesn't cost us significantly.

Differential Revision: https://reviews.llvm.org/D126435
rdar://77091379

I get to my work directory through a symlink, so the pathnames the
tests get for their build artifacts etc are via that symlink.  There
are three tests which compare those symlink paths to a directory
received from dyld on macOS, which is the actual real pathname.

These tests have always failed for me on my dekstop but I finally
sat down to figure out why. Easy quick fix.

Reviewed By: MaskRay

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

The purpose of the custom linked list was to optimize for the case
of a single-element list. It turns out that TinyPtrVector handles
the same basic scenario even better, reducing the size of
LeaderTableEntry by 33%, and requiring only log2(N) allocations
as the size of the list grows. The only downside is that we have
to store the Value's and BasicBlock's in separate vectors, which
is slightly awkward in a few cases. Fortunately that ends up being
entirely encapsulated inside helper functions.

Reviewed By: asbirlea

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

When we hoist instructions over guard we must clear flags due to these flags
might be implied using this guard, so they make sense only after the guard.

As an example of the bug due to current behavior.
L is known to be in range say [0, 100)
c1 = x u< L
guard (c1)
x1 = add x, 1
c2 = x1 u< L
guard(c2)

basing on guard(c1) we can say that x1 = add nuw nsw x, 1
after guard widening we get
c1 = x u< L
x1 = add nuw nsw x, 1
c2 = x1 u< L
c = and c1, c2
guard(c)

now, basing on fact that x + 1 < L and x >= 0 due to x + 1 is nuw
we can prove that x + 1 u< L implies that x u< L, so we can just remove c1
x1 = add nuw nsw x, 1
c2 = x1 u< L
guard(c2)

But that is not correct due to we will pass x == -1 value.

Reviewed By: mkazantsev
Subscribers: llvm-commits, nikic
Differential Revision: https://reviews.llvm.org/D126354

Running iwyu-diff on LLVM codebase since 70306542 detected a few
regressions, fixing them.

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

when we move instruction over the guard we must clear nuw/nsw flags
but we do not.

This simplifies quite a few cases where we manually duplicate the
escaping logic.

This allows for more easily interacting with lit files that utilize
the test dialect.

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

In this patch we change test cases from using "CHECK" to using
"CHECK-NEXT", which is to ensure the order of loops output by
loop cache analysis is correct. After D124725 we fixed the
non-deterministic output order hence we did not use "CHECK-DAG"
anymore, and now we should really use "CHECK-NEXT" to make sure
the loops in the output loop vector follow the right order.

Reviewed By: bmahjour, #loopoptwg

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

Reviewed By: nikic

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