[LoadStoreVectorizer] Use constant 64-bit indices for Extract/InsertElement (#208941)
The canonical form preferred by instCombine is to use 64-bit values for
constant index in ExtractElement and InsertElement.
[ELF,test] Improve .relr.auth.dyn -> .rela.dyn movement coverage (#208991)
Test two behaviors of #195649 that were unasserted:
- .dynamic shrinks when all .relr.auth.dyn entries are moved to a
non-empty .rela.dyn. Check the section header size: readelf -d stops
at the first DT_NULL and cannot show stale padding. This subsumes
empty-relr.s (a size-neutral tag swap, which passed even without the
fix), so remove it.
- An empty .rela.dyn is removed when .relr.auth.dyn is unused. Assert
this in pack-dyn-relocs-relr-loop.s.
[SLP] Use constant 64-bit indices for Extract/InsertElement (#208957)
The canonical form preferred by instCombine is to use 64-bit values for
constant index in ExtractElement and InsertElement.
[lld][ELF] Allow explicit address expressions on .tbss output sections (#196447)
D107208 allows consecutive SHF_TLS SHT_NOBITS (.tbss) output sections by
making
each .tbss start at the end address of the previous one
(state->tbssAddr). This
happens unconditionally, so an explicit output section address
(`.tbss ADDR : { ... }`) is silently ignored, unlike GNU ld.
Apply the tbssAddr fallback only when the section has no address
expression.
Some embedded/RTOS applications link the kernel and several mutually
isolated
tasks into a single ELF and require every section, .tbss included, to
sit at a
specific address matching the memory map. Placing a task's .tbss in its
own
protected region is a security boundary: one task must not be able to
[3 lines not shown]
[clang][bytecode] Remove EvalEmitter::OpPC (#208988)
We pass this when evaluting opcodes in EvalEmitter, but we never set it
to anything, so the underlying pointer is always null and we later and
up using the source location of the expression we're evaluating.
This seems to only cause problems when Statement expressions are
involved so far.
[SampleProfile] Preserve first stale profile CG match
During stale profile LCS matching, the matcher may compare the same IR function against multiple profile candidates. This can happen for overloads that share a demangled basename. The comparison result is useful for the current LCS, but rewriting FuncToProfileNameMap on every successful comparison can replace the profile selected for an IR function with a later candidate.
If another IR function is also matched to that later candidate, both functions can end up using the same stale CFG location map and runStaleProfileMatching asserts that the map is already populated.
Preserve the first selected profile mapping with try_emplace while still caching each pairwise comparison result. Add a regression with a minimal sample profile that used to trigger the assertion.
[PAC][lld] Properly handle `.relr.auth.dyn` -> `.rela.dyn` movement (#195649)
Address the following issues reported in #171475:
1. Proper adjustment of `__rela_iplt_end` address if a move from
`.relr.auth.dyn` to `.rela.dyn` took place
2. Set `__rela_iplt_start` properly if prior to such movement from
`.relr.auth.dyn`, the `.rela.dyn` was empty
3. Allocate enough space for both RELA* and AARCH64_AUTH_RELR* tags in
the `.dynamic` section in case we end up with both `.relr.auth.dyn` and
`.rela.dyn`. If one of the sections becomes empty - just pad the
`.dynamic` section with null tags in the end.
Resolves #171475
---------
Co-authored-by: Jessica Clarke <jrtc27 at jrtc27.com>
