[CIR] Upstream CIR method attribute handling (#174640)
This adds code for generating cir.method attributes and lowering them to
LLVM IR to implement support the C++ method pointer variables.
[OpenCL] Set KHR extensions minimum version to OpenCL 1.0 (#175120)
Motivation is similar to 25cfdaa4e9dc. Their spec don't specify a
required OpenCL version. Targets may expose them before OpenCL 1.2.
Set KHR extensions (depth images, mipmaps, subgroups, kernel clock, dot
product, ext_float_atomics, extended_bit_ops, cles_khr_int64) to
availability 1.0.
Changes to opencl-c.h:
* Relax header and test guards to allow extension macros whenever any
OpenCL C version is defined.
* Relax cl_khr_depth_images guard to allow cl_khr_depth_images, OpenCL
C++, or OpenCL C 2.0+, since image2d_depth_t and image2d_array_depth_t
types require that coverage.
* Guard image1d_t, image1d_array_t and image2d_array_t types with OpenCL
C++ or OpenCL C 1.2+ to match with OpenCL C spec.
Relates to https://github.com/KhronosGroup/OpenCL-CTS/pull/2376.
[lldb] Change po fallback messaging (#175847)
When an object description expression fails, instead of emitting an error, mark it as a
warning instead. Additionally, send the more low level details of the failure to the
`expr` log, and show a more user friendly message:
> `po` was unsuccessful, running `p` instead
rdar://165190497
vt(4): allow up to _SIG_MAXSIG (128) for VT_SETMODE
VT_SETMODE ioctl currently checks the provided signal numbers with its
own ISSIGVALID macro that uses NSIG (32) as a maximum, although the code
that will actually send the signal in sys/kern/kern_sig.c uses
_SIG_VALID which allows up to _SIG_MAXSIG (128).
This change aligns the vt code with the kernel internals and enables the
use of higher signal numbers so that applications are not limited to
SIGUSR1 and SIGUSR2 for vt release and acquire signals.
Signed-off-by: Quentin Thébault <quentin.thebault at defenso.fr>
Reviewed by: emaste, imp, kevans
Differential Revision: https://reviews.freebsd.org/D53615
[lldb] Fix null pointer crash in LibStdcppTupleSyntheticFrontEnd::Update (#175700)
When displaying a backtrace with std::tuple function arguments,
GetChildAtIndex() can return a null ValueObjectSP. The code was
dereferencing this pointer without checking for null, causing a SIGSEGV
crash when LLDB tried to pretty-print function arguments containing
tuples.
This PR fix the crash and add unit test which would crash before this PR
and only pass after this PR.
---------
Co-authored-by: George Hu <georgehuyubo at gmail.com>
Co-authored-by: Jonas Devlieghere <jonas at devlieghere.com>
[win][aarch64] Called globals must match for instructions to be considered identical (#175798)
When trying to enable AArch64 Import Call Optimization for Windows, we
noticed an issue where a call to an incorrect function was happening
after the loader replaced a branch instruction. The root cause of this
was that LLVM had decided to fold two branch instructions into one as
they were both branches to the same register, however the value of the
register would be different in either path as they were branches for
different imported functions.
This change updates `MachineInstr::isIdenticalTo` to also consider any
"called global" that is attached to the instruction, and will consider
two instructions as "not the same" if the globals differ.
Also fixed a possible source of non-determinism: switched from using a
`DenseMap` to using a `vector` for mapping sections to lists of called
globals (we don't expect many sections, so no need to use a map) and
sort the map by section name before emitting.
[CIR] Attempt to fold casts and unary ops during codegen (#175675)
This change introduces basic folding of casts and unary ops as they are
created this is needed in order to allow later codegen pieces, such as
builtin handlers, to more easily identify and examine constant operands.
For example, many X86 builtin functions use a default mask operand of
-1, which was previously generated as a constant 1 and a unary minus.
In some cases, the folding process leaves behind unused constant
operations, so I am also added a simple change to the canonicalize pass
to remove unused constants. We had other places where unused constants
were being generated already, and this change cleans those up too.
[clang][CodeGenCXX] Fix pragma unroll test patterns (NFC) (#175860)
These tests were not testing the loop metadata that they suggest to be
testing. They would define FileCheck variables such as `UNROLL_8` for
metadata nodes and then later redefine instead of use them (redefinition
always succeeds and thus checks nothing). The error was likely
introduced because the earlier loop metadata nodes, which must define
the variables at the first occurrence, were copy-pasted for later loop
metadata nodes, without realizing that the variable definitions in the
FileCheck pattern must be changed to uses to match later occurrences of
the same metadata node. By matching the metadata section with a block of
DAG patterns, we can define variables such as `UNROLL_8` with a pattern
that matches at the metadata node definition, even if it occurs later,
and the loop metadata nodes can be matched with uniform patterns. This
system is also used in the `pragma-loop.cpp` test.
DDT: Add locking for table ZAP destruction
Similar to BRT, DDT ZAP can be destroyed by sync context when it
becomes empty. Respectively similar to BRT introduce RW-lock to
protect open context methods from the destruction.
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Alexander Motin <alexander.motin at TrueNAS.com>
Closes #18115
[AArch64][llvm] Improve codegen for svldr_vnum_za/svstr_vnum_za
When compiling `svldr_vnum_za` or `svstr_vnum_za`, the output
assembly has a superfluous `SXTW` instruction (gcc doesn't add
this); this should be excised, see https://godbolt.org/z/sz4s79rf8
In clang we're using int64_t, and `i32` in llvm. The extra `SXTW`
is due to a call to `DAG.getNode(ISD::SIGN_EXTEND...)`. Make them
both 64bit to make the extra `SXTW` go away.
[clang-tools-extra] Update Maintainers for Clang-Doc (#175822)
Currently, Erick Velez has been doing the bulk of clang-doc development.
We're also moving one of the old maintainers that hasn't participated in
almost a year to inactive.