[CodeGenPrepare] Use recomputed split-branch weights. (#199822)
splitBranchCondition computes new branch weights after splitting an
and/or condition into two branches, but then passed the original weights
to createBranchWeights at each metadata update. The recomputed values
were discarded.
Pass the scaled NewTrueWeight/NewFalseWeight values when installing
metadata on both generated branches.
This bug was found by a large run of Opus 4.7 looking for bugs in LLVM.
[clang][deps] Disable app extensions during scanning (#200041)
Application extension contributes to the context hash, but only affects
the availability attribute on declarations. Since it cannot affect
dependencies, disable it for the scan to reduce the number of scanning
PCM variants.
[flang][FIRToMemRef] fix stride calculation for complex lowering (#200035)
**Summary**
When `fir.array_coor` targets a projected slice of a complex array (path
0 = real, 1 = imag), FIRToMemRef must not treat the result as a dense
memref.
**Bug:** The pass stopped after fir.convert to `memref<…×complex>` (or
static-shape fast path) and used default/dense strides. Loads/stores
then stepped by sizeof(complex) instead of sizeof(re)/sizeof(im).
**Fix:** For constant `%re/%im` on `complex<T>` storage:
`fir.convert` storage to `memref<…×2×T>` and index the component (0 or
1).
Read layout from `fir.box_dims` on the box (even if the memref shape is
static).
Set each memref stride to `box_dims_byte_stride / sizeof(T)`.
Advised by Cursor
netmap: silence -Wdefault-const-init-field-unsafe warning
The netmap_ring struct starts with various const members and rencent
clang warns about leaving them uninitialized. Having them const in the
first place is highly suspicious since they are updated with various
macros but using hand-coded __DECONST(). But fixing that is a more
invasive change that I am unable to test.
```
.../freebsd/sys/dev/netmap/netmap_kloop.c:320:21: error: default initialization of an object of type 'struct netmap_ring' with const member leaves the object uninitialized [-Werror,-Wdefault-const-init-field-unsafe]
320 | struct netmap_ring shadow_ring; /* shadow copy of the netmap_ring */
| ^
.../freebsd/sys/net/netmap.h:290:16: note: member 'buf_ofs' declared 'const' here
290 | const int64_t buf_ofs;
| ^
```
Test Plan: Compiles
[5 lines not shown]
if_ovpn.c: fix use of uninitialized variable
In case we use OVPN_CIPHER_ALG_NONE, the memcpy will attempt to copy 0
bytes from an uninitialized pointer. While the memcpy() implementation
will treat this as a no-op and not actually dereferece the undefined
variable it is still undefined behaviour to the compiler and should be
fixed. Found by building with clang HEAD
Reviewed by: kp
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D52543
(cherry picked from commit 969be39fb3caf4272f128dbf3267ceba5966a6ce)
netmap: silence -Wdefault-const-init-field-unsafe warning
The netmap_ring struct starts with various const members and rencent
clang warns about leaving them uninitialized. Having them const in the
first place is highly suspicious since they are updated with various
macros but using hand-coded __DECONST(). But fixing that is a more
invasive change that I am unable to test.
```
.../freebsd/sys/dev/netmap/netmap_kloop.c:320:21: error: default initialization of an object of type 'struct netmap_ring' with const member leaves the object uninitialized [-Werror,-Wdefault-const-init-field-unsafe]
320 | struct netmap_ring shadow_ring; /* shadow copy of the netmap_ring */
| ^
.../freebsd/sys/net/netmap.h:290:16: note: member 'buf_ofs' declared 'const' here
290 | const int64_t buf_ofs;
| ^
```
Test Plan: Compiles
[5 lines not shown]
if_ovpn.c: fix use of uninitialized variable
In case we use OVPN_CIPHER_ALG_NONE, the memcpy will attempt to copy 0
bytes from an uninitialized pointer. While the memcpy() implementation
will treat this as a no-op and not actually dereferece the undefined
variable it is still undefined behaviour to the compiler and should be
fixed. Found by building with clang HEAD
Reviewed by: kp
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D52543
(cherry picked from commit 969be39fb3caf4272f128dbf3267ceba5966a6ce)
[lldb] Edits and clarifications to DataFileCache comments, NFC (#199787)
I was reading through Greg Clayton's DataFileCache PR and fixed a few
small typeos as I went along.
I also had a little trouble understanding the two types of hashes that
are calculated for a file, at first, and I tried to write comments for
the relevant methods (in Module, ObjectFile, and DataFileCache) to be
more explicit about their role and the role of the other hashes that are
calculated. It may be more detail than necessary, but it would have been
helpful for me while reading this through.
[lldb] Keep addr for Memory Modules separate (#199810)
This change is to make DataFileCache symbol table caching work with
memory-read binary modules.
When we read a Module out of memory, we keep the address of the module
in Module's m_object_name field as a string. This is normally the name
of a file in a ranlib/static library/.a archive like the "main.o" in
"foo.a(main.o)". The address is most often seen in the "image list"
output, and is the only easy way to distinguish in that output which
binaries were read out of memory, versus found on local disk. The "name"
of the Module ends up being the combination of the FileSpec plus this
m_object_name.
Reading a binary out of memory is expensive, primarily because of
reading the symbol table. The DataFileCache feature that Greg introduced
five years ago can cache the Symbol Table for a binary locally, and when
we see the same binary loaded again in a future debug session/lldb
session, we can skip parsing the symbol table (or in the case of Memory
[26 lines not shown]
[libc] Add missing struct_mmsghdr dependency to sys_socket (#200051)
Updated libc/include/CMakeLists.txt to add
.llvm-libc-types.struct_mmsghdr to the sys_socket dependency list. This
ensures that the generated sys/socket.h correctly includes the
struct_mmsghdr.h type header.
Assisted-by: Automated tooling, human reviewed.
[AMDGPU] Implement -amdgpu-spill-cfi-saved-regs (#183149)
These spills need special CFI anyway, so implementing them directly
where CFI is emitted avoids the need to invent a mechanism to track them
from ISel.
Change-Id: If4f34abb3a8e0e46b859a7c74ade21eff58c4047
Co-authored-by: Scott Linder <scott.linder at amd.com>
Co-authored-by: Venkata Ramanaiah Nalamothu <VenkataRamanaiah.Nalamothu at amd.com>
[IR] Handle `expected` tag in switch branch weights. (#200025)
Switch branch weight metadata has an optional `expected` tag.
SwitchInstProfUpdateWrapper::getSuccessorWeight() did not handle this
tag; if it was present, it would return nullopt, effectively ignoring
the metadata.
This bug was found by a large run of Opus 4.7 looking for bugs in LLVM.
[SeparateConstOffsetFromGEP] Set `inbounds` correctly. (#199304)
swapGEPOperand reorders the GEPs (ptr+off)+const into (ptr+const)+off.
When it does so, it needs to determine if the inner GEP is inbounds.
Previously the way it did this was to call
stripAndAccumulateInBoundsConstantOffsets on (ptr+const), and then check
if this offset was indeed in-bounds.
However, this GEP was not necessarily marked as `inbounds` itself. If it
was not, stripAndAccumulateInBoundsConstantOffsets would return 0 for
the offset (instead of `const`), in which case we'd check if
`0 < [obj width]`, which is trivially true, and then incorrectly mark
the GEP as inbounds.
This bug was found by a large run of Opus 4.7 looking for bugs in LLVM.
ucode: Fix validation on Intel platforms
The check for the extended signature table was backwards, so we always
ignored it.
We should verify that the extended signature table fits within the total
image size.
Reviewed by: jrm, kib
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D57209
[AMDGPU] Speedup canBeVOPD()
Generate static table from tablegen instead of trying to
create a full VOPD opcode just to see if that is possible.
Ideally it shall be single table with info for both X and
Y components and non-VOPD opcode as a primary key, although
I do not think we can genere it now.
[flang][OpenMP] Event handles are not predetermined shared
Am event-handle variable that appears in a DETACH has its data-sharing
attributes determined according to the usual rules in the constructs
enclosing the clause.
ctl: Use CAM_PRIORITY_NORMAL for queued CCBs
Previously this was using CAM_PRIORITY_NONE which tripped over the
assertion added in b4b166b8c46b8.
PR: 293076
Reported by: Ken J. Thomson <thomsonk at yandex.com>
Reviewed by: imp
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D56995
