Those nullptr checks are after we already accessed the pointer.

Reviewed By: labath

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

https://reviews.llvm.org/D108392



Signed-off-by: Kevin Petit <kevin.petit@arm.com>

Function specialisation was running at all optimisation levels (if enabled on
the command line, it is not on by default). That was an oversight and not
something we want to do. Function specialisation duplicates functions when it
triggers, so the backend is processing more functions/instructions resulting in
compile-time increases, which seems more appropriate with -O3 and inline with
GCC. Please note that since function specialisation is not enabled by default,
this didn't require updating any pass manager tests.

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

Reviewed By: labath

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

This allows shipping individual functions without also having to provide
memset or bzero at the expense of bigger functions.

Similar to D113097.

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

Similar to D113097 although not strictly necessary for now. It helps
keeping the same structure for all memory functions.

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

This allows shipping individual functions without also having to provide
`memcpy` at the expense of bigger functions.
Next is to use this `inlined_memcpy` in:
 - loader/linux/x86_64/start.cpp
 - src/string/memmove.cpp
 - src/string/mempcpy.cpp
 - src/string/strcpy.cpp
 - src/string/strdup.cpp
 - src/string/strndup.cpp

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

This patch removes unnecessary comments in the flang-omp-report
plugin tests which can be implied from the file name and run command.

Reviewed By: awarzynski

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

Ensure that the destination slot exists in this case. This addresses PR51484.

rG1e5f8143 added the test case, I've added PR52397 to the comment to help keep track of the source of the bug

Check both operands for zero elements to remove unnecessary demanded elts.

Try to help reduce some minor regressions noticed in D110995

CPSR on Arm64 is 4 bytes in size but windows on Arm implementation is trying to read/write 8 bytes against a byte register causing LLDB unit tests failures.

Ref: https://docs.microsoft.com/en-us/windows/win32/api/winnt/ns-winnt-arm64_nt_context

Reviewed By: mstorsjo

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

LIT skips various system environment variables while building test
config. It turns out that we require PLATFORM environment variable for
detection of x86 vs Arm windows platform.

This patch adds system environment variable PLATFORM into LIT test
config for detection of win32 Arm platform.

Reviewed By: mstorsjo

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

As seen in https://bugs.llvm.org/show_bug.cgi?id=52213 llvm-objdump
asserts if either the --debug-vars or the --dwarf options are provided
with invalid values. As suggested, this fix adds use of a default value
to these options and errors when given bad input.

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

Coroutines have weird semantics that don't quite match normal LLVM functions,
so trying to infer even simple attributes based on thier contents can go wrong.

Convert fir.insert_on_range operation to corresponding
llvm.insertvalue operations.

This patch is part of the upstreaming effort from fir-dev branch.

Reviewed By: mehdi_amini

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

The added test has poison lanes due to the vector shuffle. This can
cause an infinite loop of combines in instcombine where it folds
xor(ashr, -1) -> select (icmp slt 0), -1, 0 -> sext (icmp slt 0) -> xor(ashr, -1).
We usually prevent this by checking that the xor constant is not -1,
but with vectors some of the lanes may be -1, some may be poison. So
this changes the way we detect that from "!C1->isAllOnesValue()" to
"!match(C1, m_AllOnes())", which is more able to detect that some of the
lanes are poison.

Fixes PR52397

These are not standard methods, neither libstdc++ nor MSVC STL provide
them.

In practice, one of them was untested and the other one was only used in
one single test.

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

In 7f01f785 [lldb] update TestEchoCommands -- I fixed this test,
but not on windows, becuase I used  some unix shell syntax that
doesn't work with cmd.exe.   Fixed it so it will work in both.
Test logic is the same.

This is a trivial fix, so bypassing review to get the build clean again
ASAP.

Sequence type had no restriction on the insert_on_range operation.
This patch adds a restriction for the type to have constant shape
and size.

Reviewed By: mehdi_amini

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

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

This undocumented ld64 flag, based on the most recent ld64 source dump
from Xcode 12, only applies to i386. It seems like on all newer
architectures this behavior is the default.

Reviewed By: #lld-macho, int3

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

In one of our links lld was reading 760k files, but the unique number of
files was only 1500. This takes that link from 30 seconds to 8.

This seems like a heavy hammer, especially since some things don't need
to be cached, like the filelist arguments and the passed static
archives (the latter is already cached as a one off), but it seems ld64
does something similar here to short circuit these duplicate reads:

https://github.com/keith/ld64/blob/82e429e186488529111b0ef86af33a3b1b9438c7/src/ld/InputFiles.cpp#L644-L665

Of the types of files being read for our iOS app, the biggest problem
was constantly re-reading small tbd files:

```
% wc -l /tmp/read.txt
761414 /tmp/read.txt
% cat /tmp/read.txt | sort -u | wc -l
1503

% cat /tmp/read.txt | grep "\.a$" | wc -l
43721
% cat /tmp/read.txt | grep "\.tbd$" | wc -l
717656
```

We could likely hoist this logic up to not cache at this level, but it
would be a more invasive change to make sure all callers that needed it
cached the results.

I could see this being an issue with OOMs, and I'm not a linker expert so
maybe there's another way we should solve this problem? Feedback welcome!

Reviewed By: int3, #lld-macho

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

By default with ld64, architecture mismatches are just warnings, then
this flag can be passed to make these fail. This matches that behavior.

Reviewed By: int3, #lld-macho

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

This allows for external users of Comprehensive Bufferize to specify their own InitTensorOp elimination procedures.

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

D101513 means that we no longer need to specify `-pie` in most of our
test RUN commands. Let's clean up the unused flags so as not to confuse
future test writers.

Reviewed By: #lld-macho, oontvoo, MaskRay

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

Now in libcxx and clang, all the coroutine components are defined in
std::experimental namespace.
And now the coroutine TS is merged into C++20. So in the working draft
like N4892, we could find the coroutine components is defined in std
namespace instead of std::experimental namespace.
And the coroutine support in clang seems to be relatively stable. So I
think it may be suitable to move the coroutine component into the
experiment namespace now.

This patch would make clang lookup coroutine_traits in std namespace
first. For the compatibility consideration, clang would lookup in
std::experimental namespace if it can't find definitions in std
namespace. So the existing codes wouldn't be break after update
compiler.

And in case the compiler found std::coroutine_traits and
std::experimental::coroutine_traits at the same time, it would emit an
error for it.

The support for looking up std::experimental::coroutine_traits would be
removed in Clang16.

Revi...

Floating point results mismtach between Visual stdio 2019 and previous
versions. This adjusts macro accordingly.

Currently, FPSCR is not modeled, so in some early passes (such as
early-cse), the read/set intrinsics to FPSCR may get incorrect
simplification.

Reviewed By: jsji

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

This expands the lookup table statically and avoids routing through methods that
contain asserts (like StringRef/std::string element accessors and drop_front)
such that performance is more predictable across compilation environments. This
was primarily driven by slow debug mode performance but has a large benefit in
release builds as well.

```
ssd_mobilenet_v2_face_float (42MB .mlir)
  Debug/MSVC (old):  5.22s
  Debug/MSVC (new):  0.16s
Release/MSVC (old):  0.81s
Release/MSVC (new):  0.02s

huggingface_minilm (536MB .mlir)
  Debug/MSVC (old): 65.31s
  Debug/MSVC (new):  2.03s
Release/MSVC (old):  9.93s
Release/MSVC (new):  0.27s
```

Now in debug the time is split evenly between lexString, tryGetFromHex, and
element attrs hashing, with the next step to making it faster being to combine
the work (incremental hashing during conversion, etc) - but this is at least in
the right order of magnitude and retains the original API surface.

I have not profiled a build with clang but this is strictly less code and simpler
data structures so I'd expect improvements there as well.

This also fixes a bug where 0xFF bytes in the input would read out of bounds.

Reviewed By: dblaikie, stellaraccident

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

There is no real source location for code inside prologue as it is
generated by compiler but source locations are being added to code
inside prologue as a side effect of https://reviews.llvm.org/D99269
because buildSpillLoadStore() is using source location of the real
instruction in the basic block if any.

Fixes: SWDEV-307590

Reviewed By: scott.linder, sebastian-ne

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

This reverts commit 593275c9.

This test now passes again.

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

By default `llvm::seq` would happily iterate over enums, which may be unsafe if the enum values are not continuous. This patch disable enum iteration with `llvm::seq` and `llvm::seq_inclusive` and adds two new functions: `enum_seq` and `enum_seq_inclusive`.

To make sure enum iteration is safe, we require users to declare their enum types as iterable by specializing `enum_iteration_traits<SomeEnum>`. Because it's not always possible to add these traits next to enum definition (e.g., for enums defined in external libraries), we provide an escape hatch to allow iteration on per-callsite basis by passing `force_iteration_on_noniterable_enum`.

The main benefit of this approach is that these global declarations via traits can appear just next to enum definitions, making easy to spot when enums are miss-labeled, e.g., after introducing new enum values, whereas `force_iteration_on_noniterable_enum` should stand out and be easy to grep for.

This emerged from a discussion with gchatelet@ about reusing llvm's `Sequence.h` in lieu of https://github.com/GPUOpen-Drivers/llpc/blob/dev/lgc/interface/lgc/EnumIterator.h.

Reviewed By: dblaikie, gchatelet, aaron.ballman

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

Revert "Fix iterator_adaptor_base/enumerator_iter to allow composition of llvm::enumerate with llvm::make_filter_range"

This reverts commit ba7a6b31.

Post-commit review showed that the fix implemented wasn't correct, and a
more principled fix is possible.

For each selector encountered in the source code, we need to load
selectors from the imported modules and check that we are calling a
selector with compatible types.

At the moment, for each module we are storing methods declared in the
headers belonging to this module and methods from the transitive closure
of imported modules. When a module is imported by a few other modules,
methods from the shared module are duplicated in each importer. As the
result, we can end up with lots of identical methods that we try to add
to the global method pool. Doing this duplicate work is useless and
relatively expensive.

Avoid processing duplicate methods by storing in each module only its
own methods and not storing methods from dependencies. Collect methods
from dependencies by walking the graph of module dependencies.

The issue was discovered and reported by Richard Howell. He has done the
hard work for this fix as he has investigated and provided a detailed
explanation of the performance problem.

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

rename str_conv_utils to str_to_integer to be more
in line with str_to_float.

Reviewed By: sivachandra, lntue

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