420d7ccb introduced BACKEND_PACKAGE_STRING to
replace `PACKAGE_VERSION` (llvm/Config/config.h) to support standalone builds.
This is used in the output of `clang -cc1 -v`.

Since llvm-config.h is available for both standalone and non-standalone builds,
we can just use `LLVM_VERSION_STRING` from llvm-config.h.

clang/cmake/modules/AddClang.cmake uses `VERSION_STRING "${CLANG_VERSION} (${BACKEND_PACKAGE_STRING})"`.
Just simplify it to `"${CLANG_VERSION}"` so that we can remove the CMake
variable BACKEND_PACKAGE_STRING.

Reviewed By: tstellar

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

Reviewed By: MaskRay

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

For more details about these instructions, please refer to the latest ISE document: https://www.intel.com/content/www/us/en/develop/download/intel-architecture-instruction-set-extensions-programming-reference.html

Reviewed By: pengfei, skan

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

This allows all ELF operating systems to use target specifics tuned for Linux,
since they use mostly the same ABIs. If some triples are to excluded, it's
better done at the driver layer.

Reviewed By: emaste

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

This has been a long standing TODO, and actually enables users to generate
debug information for LLVM using the LLVM dialect; as opposed to our
dummy placeholder that generated just enough for line table information.

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

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

If the immediate is negative with sufficient leading ones, then
the upper bits of the other operand aren't demanded.

This allows vectors to be looked up if the switch is used for the
scalar version of an intrinsic.

Extracted from D136508.

Extracted from D136508.

The token that records the number of closing braces to be inserted
may be on an unaffected line. Extra work is required in order to
actually insert the closing braces after inserting the matching
opening braces of affected lines.

Fixes #58161.

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

As Fortran 2018 C1546, an elemental procedure shall not have the BIND
attribute.

As 18.3.6, it does not mention that an array with VALUE can be
interoperable. It is not reasonable to pass an array by value when the
array is too large. Forbid it to be consistent with gfortran/ifort.

Reviewed By: jeanPerier

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

The quad precision kind is defined as 8 by default in
flang/include/flang/Common/default-kinds.h. However, it should be target
dependent. This fixes the default quad precision kind when the target
is on X86_64.

Reviewed By: klausler

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

When COMPILER_RT_BUILD_MEMPROF is disabled, the memprof headers should not be installed.

Reviewed By: mgorny, tejohnson

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

In Android, further initialization is always necessary whether preinit_array can be used.
LazyInitialize is needed regardless of .preinit_array support on platforms where runtime is loaded as dynamic library, e.g. Android.

Reviewed By: dvyukov, vitalybuka

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

The 'guess' language triggers a warning in the polly-sphinx-docs:
https://lab.llvm.org/staging/#/builders/199/builds/209
which is treated as an error by default.

This might be related to the Sphinx bug
https://github.com/sphinx-doc/sphinx/issues/7139

Fixes GH58547.

Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>

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

Additional calls were introduced for outlining (opposite of inlining)
in https://reviews.llvm.org/D136197 which contain asserts that partial
poisoning of a single byte wouldn't happen consecutively but this is
too strong and actually does occur in Windows. Removing those asserts
as they are unnecessary

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

This addresses a bug where vector versions of ctlz are creating false positive reports.

Depends on D136369

Reviewed By: vitalybuka

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

Reviewed By: michaelrj

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

Reviewed By: vitalybuka

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

Fix breakpoint setting so it always works when there is a line entry in a compile unit's line table.

Prior to this fix, if the compile unit function:

  void CompileUnit::ResolveSymbolContext(const SourceLocationSpec &src_location_spec, SymbolContextItem resolve_scope, SymbolContextList &sc_list);

was called with a resolve scope that wasn't just eSymbolContextLineEntry, we would end up calling:

  line_entry.range.GetBaseAddress().CalculateSymbolContext(&sc, resolve_scope);

This is ok as long as the line entry's base address is able to be resolved back to the same information, but there were problems when it didn't. The example I found was we have a file with a bad .debug_aranges section where the address to compile unit mapping was incomplete. When this happens, the above function call to calculate the symbol context would end up matching the module and it would NULL out the compile unit and line entry, which means we would fail to set this breakpoint. We have many other clients that ask for eSymbolCon...

Build fix.

Reviewed By: rtenneti

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

Removes a bunch of obsolete methods in favor of a single one returning
an ArrayRef of TemplateArgument.

Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>

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

The difftime function computes the difference between two calendar
times: time1 - time0 as per as per 7.27.2.2 section in
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2478.pdf

.

  double difftime(time_t time1, time_t time0);

Tested:
Unit tests

Co-authored-by: Jeff Bailey <jeffbailey@google.com>

Reviewed By: jeffbailey

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

Set target triple to "dxil-ms-dx" for DXIL at the end of DXILTranslateMetadata.

Reviewed By: beanz

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

When -asan-max-inline-poisoning-size=0, all shadow memory access should be
outlined (through asan calls). This was not occuring when partial poisoning
was required on the right side of a variable's redzone. This diff contains
the changes necessary to implement and utilize  __asan_set_shadow_01() through
__asan_set_shadow_07(). The change is necessary for the full abstraction of
the asan implementation and will enable experimentation with alternate strategies.

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

Previously, EPCEHFrameRegistrar always used the
ExecutorProcessControl::loadDylib(nullptr) method to obtain a handle for the
process, but this doesn't work if the registration functions aren't visible in
a standard search of the process (e.g. if the JIT is in a plugin that is loaded
with RTLD_LOCAL).

This patch retains the old behavior by default, but allows clients to supply
their own handle for the library containing the registration functions if they
need to (e.g. to work around limitations like RDLD_LOCAL above, which aren't
expressible within the existing loadDylib / DynamicLibrary APIs).

Updates tpctypes::DylibHandle to be an ExecutorAddr (rather than a uint64_t),
and SimpleExecutorDylibManager to hold and return raw OS handle values (as
ExecutorAddrs) rather than index values into a map of DynamicLibrary instances.

This will allow clients to use EPCGenericDylibManager in contexts where the
existing DynamicLibrary interface is too limited to be used. (e.g. to look up
JIT symbols in a dylib that was loaded with RTLD_LOCAL).

This is a sibling transform to the fold just above it. That was changed
to allow the corresponding commuted patterns with:
30730745
e1bd759e
8628e6df

This should address the failure found by:
https://lab.llvm.org/buildbot/#/builders/231/builds/4152

Fixed compile time increase due to always constructing LocalCostTracker.
Now only construct LocalCostTracker when needed.

A common post condition of the various visitor functions in CodeGen is that instructions, that do not return any values, simply return a nullptr Value as a sentinel. This has not been the case however for calls to some builtins returning void, as well as for an initializer expression of the form `void()`. This would then lead to ICEs in CodeGen on code relying on nullptr being returned for void values, which is eg. the case for conditional expressions [0].
This patch fixes that by returning nullptr Values for intrinsics known not to return any values as well as for a scalar initializer returning void.

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

[0] https://github.com/llvm/llvm-project/blob/266ec801fb23f9f5f1d61ca9466e0805fbdb78a7/clang/lib/CodeGen/CGExprScalar.cpp#L4849-L4892

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

RISC-V vectors are basically vectors, but we use builtin types to
restrict the possible types. Treat them the same as vectors and scalars
for this analysis.

Reviewed By: reames

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

This reverts commit cecc9a92.

The problem ended up being how we were handling the lambda-context in
code generation: we were assuming any decl context here would be a
named-decl, but that isn't the case.  Instead, we just replace it with
the concept's owning context.

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