This alignment guarantee enables simpler group range check while page
releasing and a potential optimization which is, now all the pointers
from the same group are also inth same region, that means the complexity
in markFreeBlocks() can be reduced as well.

Reviewed By: cferris

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

This reverts commit 03e5c46e.

This overlaps partially with the codegen patch D144789. This needs no-wrap
for correctness, and I'm not sure if there's an unsigned equivalent:
https://alive2.llvm.org/ce/z/ErmQ-9
https://alive2.llvm.org/ce/z/mr-c_A

This is obviously an improvement in IR, and it looks like a codegen win
for all targets and data types that I sampled.

The 'nabs' case is left as a potential follow-up (and seems less likely
to occur in real code).

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

Enable completion of variables for `dwim-print` command.

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

Add basic tests for `frame variable`'s ability to direct access fields of `this` and
ivars of `self`.

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

Also pipe empty string to the commandline test to make sure it does
not hang on some configurations.

Fixes #61104

Without this patch:

  %cond = call i32 @llvm.umax.i32(i32 %X, i32 1)

is compiled as:

  83 ff 02                   cmp    $0x2,%edi
  b8 01 00 00 00             mov    $0x1,%eax
  0f 43 c7                   cmovae %edi,%eax

With this patch, the compiler generates:

  89 f8                      mov    %edi,%eax
  83 ff 01                   cmp    $0x1,%edi
  83 d0 00                   adc    $0x0,%eax

saving 3 bytes.  We should be able to save 5 bytes in larger functions
where the mov is unnecessary.

This patch converts the specific cmov pattern to cmp $1 followed by
adc $0.

This patch partially fixes:

https://github.com/llvm/llvm-project/issues/60374

The LLVM IR optimizer is yet to canonicalize max expressions to
actual @llvm.umax.

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

Shows the failure of combineBitcastvxi1 to sign-extend a select(i1,vXi1,vXi1) pattern

Fix some minor errors in the code-block sections of the new pass manager documentation

Reviewed By: aeubanks

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

Clang -march= for ppc triples currently leads to an
-Wunused-command-line-argument warning but GCC rejects -march=.

    error: unrecognized command-line option ‘-march=xxx’

Let's reject -march= as well similar to the Sparc change D130273.

Close https://github.com/llvm/llvm-project/issues/57587

Reviewed By: #powerpc, nemanjai

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

We can infer more attribute information once functions are fully
simplified, so move the PostOrderFunctionAttrs pass after the function
simplification pipeline. However, just doing this can impact
simplification of recursive functions since function simplification
takes advantage of function attributes of callees (some LLVM tests are
actually impacted by this), so keep a copy of PostOrderFunctionAttrs
before the function simplification pipeline that only runs on recursive
functions.

For example, this fixes the small regression noticed in https://reviews.llvm.org/D128830.

This requires some restructuring of the CGSCC NoRerun feature. We need
to cache the ShouldNotRunFunctionPassesAnalysis analysis after the
simplification is done, which now is after the second
PostOrderFunctionAttrs run, rather than after the function
simplification pipeline.

Compile time impact:
https://llvm-compile-time-tracker.com/compare.php?from=33cf40122279342b50f92a3a53f5c185390b6018&to=1bb2a07875634e508a6bdf2ca1b130f55510f060&stat=instructions:u

Compile time increase from unconditionally running the first PostOrderFunctionAttrs:
https://llvm-compile-time-tracker.com/compare.php?from=1bb2a07875634e508a6bdf2ca1b130f55510f060&to=f4f87e89cc7a35c64e3a103a8036192a84ae002b&stat=instructions:u

Reviewed By: nikic

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

For pipeline tests.

When an alias or ifunc attribute refers to a function name that is
mangled, a diagnostic is emitted to suggest the mangled name as a
replacement for the given function name for every matching name in the
current TU.

Fixes #59164

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

In D144997, the dynamic type of polymorphic entities is reset to the declared
type when the FROM is deallocated. To do this, the declared type was passed as
a fir.type_desc op. For unlimited polymorphic entities, this should just be a
null pointer.

Reviewed By: PeteSteinfeld

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

The Destroy runtime function does free the memory so do not do it
inlined when we use Destroy. This avoid a double free execution error.

Reviewed By: PeteSteinfeld

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

https://wg21.link/LWG2444 updated the comparison complexity of
std:sort_heap to be at most 2N log (N) where N == last - first.  In the
current implementation, we invoke __pop_heap exactly N-1 times.  In each
call to __pop_heap, we first go down the heap from first to possibly
last in the function __floyd_sift_down.  Then, we possibly go back up in
the function __sift_up.

In the function __floyd_sift_down, there is loop in which one comparison
is made in each iteration.  The loop runs till __child becomes greater
than (__len - 2) / 2.  __child starts at 0 and it is at least set to 2 *
__child + 1 on each iteration.  Thus, after k iterations, __child will
be at least 2^k - 1.  After log(N) iterations,  __child >= 2^(log(N)) -
1 = N - 1 > (__len - 2) / 2.  This means that the while loop in the
function __floyd_sift_down would perform at most log(N) comparisons on
each invocation.

In the function __sift_up, there is one comparison made that will almost
always occur.  After that there is a do-while loop.  The comparison
function is invoked once in each iteration.  In the worst case, the loop
will run till __len goes down to zero.  It can start from (N-3)/2.  In
each iteration, __len goes down to (__len-1) / 2.  After k iterations,
__len will be at most (N - 2^(k+1) -1) / 2^(k+1).  Thus, __len will
become  when (N-2^(k+1)-1) < 2^(k+1)  i.e. N  < 2^(k+2) + 1.  This means
at most log(N) - 1 iterations for the loop.  So in total at most log(N)
  comparison will be performed in __sift_up.

So overall for each iteration of the loop in __pop_heap, there will at
most 2 log(N) comparisons.  So, the total number of comparisons is
at most 2 N log(N).

We also updated the test sort.heap/complexity.pass.cpp to test for the
number of operations.

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

This is a flaky test and may not test the thing it expected to verify.
E.g., it doesn't dirty the pages so the memory usage may not be reflected
on the RSS.

Reviewed By: cferris

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

We have the heuristic to determine the threshold of doing page
releasing for smaller size classes. However, in a case that the
memory usage is bouncing between that threshold may result in
frequent try of page releasing but not returning much memory.

This CL add another heuristic to mitigate this problem by increasing
the minimum pages that potentially can be released. Note that this
heuristic is only applied on SizeClassAllocator64. SizeClassAllocator32
has a smaller group size so the overhead is smaller than 64-bit
platform.

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

This reverts commit daaef4c4.

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

It turns out that there are relatively trivial, albeit rare, cases that
require a MaxDepth of more than 16 (see added test). However, we want to
avoid having to rely on a large fixed MaxDepth.

Since these cases are relatively rare, apply the following strategy:

  1. Start with a low MaxDepth of 16 - if the entry node was not
     reached, we can return (the common case).

  2. If the entry node was reached, exponentially increase MaxDepth up
     to some large limit that should cover all cases and guard against
     stack exhaustion.

This retains the better performance with a low MaxDepth in the common
case, and in complex cases backs off and retries. On a whole, this is
preferable vs. starting with a large MaxDepth which would unnecessarily
penalize the common case where a low MaxDepth is sufficient.

Reviewed By: dvyukov

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

*  Use inheriting constructors declarations to avoid introducing the
   `Base` typedef and duplicate constructor definitions. This should make
   things cleaner, especially since `zip_common` also exposes a `Base`
   typedef.
*  Drop unnecessary template parameters.
*  Avoid double negation in `zip_shortest`'s `operator==` and rename the
   comparison function for better readability.

Reviewed By: zero9178

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

Minor fix to Issue #61104

Shows the failure of combineBitcastvxi1 to sign-extend a vXi1 allones vselect operand

There's a number of other problems in Issue #61104 still to address, but this one has an easy quick fix

Reviewed By: lntue

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

We explicitly state that the `reference` type for Sequence iterator is a `value_type`.
Since the iterator is a lazy generator, it cannot point to any memory and so it cannot have a reference type.
Fixes https://github.com/llvm/llvm-project/issues/61122

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

Usually PDB files have a string table (aka: Named Stream "/names" ). PDB for
some windows system libraries might not have that. This adds the check for it to
avoid crash in the absence of string table.

Reviewed By: labath

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

Rename DebugAction to tracing::Action and move related code from lib/Support to lib/IR and lib/Debug

This is a preparation for adding support for more infrastructure around the concept
of Action and make tracing Action more of a first class concept.
The doc will be updated later in a subsequent revision after the changes are
completed.

Action belongs to IR because of circular dependency: Actions are dispatched through
the MLIRContext but Action will learn to encapsulate IR construct.

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

All the fc* floating point conversion PowerPC intrinsics are simply lowered to their LLVM IR intrinsic counterparts and do not require any additional error checking.

Reviewed By: klausler, jeanPerier

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

At the moment, we invoke `shouldExecute()` that way:

```
if (manager.shouldExecute<DebugAction>(currentOp) {
  // apply a transformation
  …
}
```

In this sequence, the manager isn’t involved in the actual execution
of the action and can’t develop rich instrumentations. Instead the API
could let the control to the handler itself:

```
// Execute the action under the control of the manager
manager.execute<DebugAction>(currentOp, [&]() {
  // apply the transformation in this callback
  …
});
```

This inversion of control (by injecting a callback) allows handlers to
implement potentially new interesting features: for example, snapshot
the IR before and after the action, or record an action execution time.
More importantly, it will allow to capture the nesting execution of
actions.

On the other side: handlers receives now a DebugAction object that wraps
generic information (tag and description especially) as well as
action-specific data.

Finally, the DebugActionManager is now enabled in release builds as
well.

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

Similar to most of the other vector-shuffle-* test files

Avoids some codegen deltas due to upcoming changes for no-costs domain switching between shuffle types

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

This patch adds an implementation of ieee_is_normal using a call
to llvm.is.fpclass.

Depends on D144649

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

Optional character function arguments were not being lowered
properly. As they are passed as a tuple, containing the (boxed)
function address and the character length, it is not possible for
fir.absent to handle it directly. Instead, a tuple needs to be
created and filled with an absent function address and a dummy
character length.

Fixes #60225

Reviewed By: jeanPerier

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