Previously, `type lookup` for types in namespaces didn't work with the
native PDB plugin, because `FindTypes` would only look for types whose
base name was equal to their full name. PDB/CodeView does not store the
base names in the TPI stream, but the types have their full name (e.g.
`std::thread` instead of `thread`). So `findRecordsByName` would only
return types in the top level namespace.
This PR changes the lookup to go through all types and check their base
name. As that could be a bit expensive, the names are first cached
(similar to the function lookup in the DIA PDB plugin). Potential types
are checked with `TypeQuery::ContextMatches`.
To be able to handle anonymous namespaces, I changed
`TypeQuery::ContextMatches`. The [`TypeQuery`
constructor](9ad7edef42/lldb/source/Symbol/Type.cpp (L76-L79))
inserts all name components as `CompilerContextKind::AnyDeclContext`. To
skip over anonymous namespaces, `ContextMatches` checked if a component
was empty and exactly of kind `Namespace`. For our query, the last check
was always false, so we never skipped anonymous namespaces. DWARF
doesn't have this problem, as it [constructs the context
outside](abe93d9d7e/lldb/source/Plugins/SymbolFile/DWARF/DWARFIndex.cpp (L154-L160))
and has proper information about namespaces. I'm not fully sure if my
change is correct and that it doesn't break other users of `TypeQuery`.
This enables `type lookup <type>` to work on types in namespaces.
However, expressions don't work with this yet, because `FindNamespace`
is unimplemented for native PDB.
Similar to 742ecfc13e8aa34cfff2900e31838f657fcafe30 for MCFillFragment,
ensure `.org` directives with expressions are re-evaluated during
fragment relaxation, as their sizes may change. Continue iteration to
prevent stale, incorrect sizes. While I knew MCOrgFragment likely needed
to be re-evaluated at all, I did not have a motivation to add it;-)
This fixes the root cause of
https://github.com/ClangBuiltLinux/linux/issues/2116
(writeSectionData assertion failure when building the Linux kernel for arm64)
The issue cannot be reliably replicated. The specific test case would
not replicate if any of the following condition was not satisfied:
* .org was not re-evaluated. Fixed by this commit.
* clang -cc1as has a redundant `initSections` call, leading to a
redundant initial FT_Align fragment. llvm-mc -filetype=obj, lacking
the redundant `initSections`, doesn't replicate.
* faa931b717c02d57f0814caa9133219040e6a85b decreased sizeof(MCFragment).
* f1aa6050bd90f8ec4273da55d362e23905ad3a81 added more fragments
This patch adds support for converting memset calls to one or more
`QC_SETWMI` instructions when beneficial. We only handle aligned memset
calls for now.
We limit a `QC_SETWMI` to 16 words or less to improve interruptibility.
So for `1-16` words we use a single `QC_SETWMI`:
`QC_SETWMI reg1, N, 0(reg2)`
For `17-32 `words we use two `QC_SETWMI's` with the first as 16 words
and the second for the remainder:
```
QC_SETWMI reg1, 16, 0(reg2)
QC_SETWMI reg1, N, 64(reg2)
```
For `33-48` words, we would like to use `(16, 16, n)`, but that means
the last QC_SETWMI needs an offset of `128` which the instruction
doesn't support. So in this case we use a length of `15` for the second
instruction and we do the rest with the third instruction.
This means the maximum number of words handled is `47` (for now):
```
QC_SETWMI R2, R0, 16, 0
QC_SETWMI R2, R0, 15, 64
QC_SETWMI R2, R0, N, 124
```
For `48` words or more, call the target independent memset.
The lifetime argument is now required to be an alloca, so we should not
try to replace it with a constant.
We also shouldn't try to change the size argument to zero/one, similar
to how we avoid zero-size allocas.
This is a first pass at implementing
[P2841R7](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p2841r7.pdf).
The implementation is far from complete; however, I'm aiming to do that
in chunks, to make our lives easier.
In particular, this does not implement
- Subsumption
- Mangling
- Satisfaction checking is minimal as we should focus on #141776 first
(note that I'm currently very stuck)
FTM, release notes, status page, etc, will be updated once the feature
is more mature. Given the state of the feature, it is not yet allowed in
older language modes.
Of note:
- Mismatches between template template arguments and template template
parameters are a bit wonky. This is addressed by #130603
- We use `UnresolvedLookupExpr` to model template-id. While this is
pre-existing, I have been wondering if we want to introduce a different
OverloadExpr subclass for that. I did not make the change in this patch.
This reverts commit f1aa6050bd90f8ec4273da55d362e23905ad3a81 (reland of #150846),
fixing conflicts.
It caused https://github.com/ClangBuiltLinux/linux/issues/2116 ,
which surfaced after a subsequent commit faa931b717c02d57f0814caa9133219040e6a85b decreased sizeof(MCFragment).
```
% /tmp/Debug/bin/clang "-cc1as" "-triple" "aarch64" "-filetype" "obj" "-main-file-name" "a.s" "-o" "a.o" "a.s"
clang: /home/ray/llvm/llvm/lib/MC/MCAssembler.cpp:615: void llvm::MCAssembler::writeSectionData(raw_ostream &, const MCSection *) const: Assertion `getContext().hadError() || OS.tell() - Start == getSectionAddressSize(*Sec)' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0. Program arguments: /tmp/Debug/bin/clang -cc1as -triple aarch64 -filetype obj -main-file-name a.s -o a.o a.s
Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it):
0 libLLVMSupport.so.22.0git 0x00007cf91eb753cd llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) + 61
fish: Job 1, '/tmp/Debug/bin/clang "-cc1as" "…' terminated by signal SIGABRT (Abort)
```
The test is sensitive to precise fragment offsets. Using llvm-mc
-filetype=obj -triple=aarch64 a.s does not replicate the issue. However,
clang -cc1as includes an unnecessary `initSection` (adding an extra
FT_Align), which causes the problem.
I'm assuming this was the set of targets that were relevant
for sjlj handling. Just take the raw exception setting instead,
and assume it makes sense for the target.
The isUnset state lacks significance and should be treated as equivalent
to an undefined symbol.
Equated and common symbols seem to have subtle semantic distinctions in
GAS, justifying the use of distinct `SymContents*` values.
TODO: Ensure common symbols have a fragment, so that `isDefined()`
returns true, rejecting `.comm c, 4, 4; .set c, 4`
"unset" is not a meaningful separae state and it will be merged into
"undefined".
https://reviews.llvm.org/D72570 ported a GAS hack that moves the label
when a prefixed instruction on the same source line needs automatic
alignment. However, we can used isDefined instead of isUnset.
The unset state will be merged into the undefined state,
so isUnset should be avoided.
The code used by register equating uses the inaccurate condition.
```
.set r1, $4
```
For now just use isUndefined. GNU Assembler has a warning:
```
Warning: register value used as expression
```
The object file format specific derived classes are used in context
where the type is statically known. We don't use isa/dyn_cast and we
want to discourage dynamic dispatching on the type.
These are already the default calls set for these conversions, so
they should not require explicit setting. The non-default cases are
currently overridden in ARMISelLowering. Just delete this until
the list of calls and lowering decisions are separated.
This was added back in 6402ad27c01c9503a12d41d7e40646cf0d1f919f. It
appears to not be relevant for AArch64, where calls appear to never
be used for these. It also appears to not be relevant for x86, where
the default calls seem to always end up used anyway.
The object file format specific derived classes are used in context
where the type is statically known. We don't use isa/dyn_cast and we
want to eliminate MCSymbol::Kind in the base class.
There is a case when branch profile metadata is OK to miss, namely, cold functions. The goal of the RFC (see the referenced issue) is to avoid accidental omission (and, at a later date, corruption) of profile metadata. However, asking cold functions to have all their conditional branches marked with "0" probabilities would be overdoing it. We can just ask cold functions to have an explicit 0 entry count.
This patch:
- injects an entry count for functions, unless they have one (synthetic or not)
- if the entry count is 0, doesn't inject, nor does it verify the rest of the metadata
- at verification, if the entry count is missing, it reports an error
Issue #147390
The object file format specific derived classes are used in context
where the type is statically known. We don't use isa/dyn_cast and we
want to eliminate MCSymbol::Kind in the base class.
The object file format specific derived classes are used in context
where the type is statically known. We don't use isa/dyn_cast and we
want to eliminate MCSymbol::Kind in the base class.
The object file format specific derived classes are used in context
where the type is statically known. We don't use isa/dyn_cast and we
want to eliminate MCSymbol::Kind in the base class.
The object file format specific derived classes are used in context
where the type is statically known. We don't use isa/dyn_cast and we
want to eliminate MCSymbol::Kind in the base class.
The object file format specific derived classes are used in context
where the type is statically known. We don't use isa/dyn_cast and we
want to eliminate MCSymbol::Kind in the base class.
The object file format specific derived classes are used in context
where the type is statically known. We don't use isa/dyn_cast and we
want to eliminate MCSymbol::Kind in the base class.
Hack in the default setting so it's consistently generated like
the other cases. Maintain a list of targets where this applies.
The alternative would require new infrastructure to sort the system
library initialization in some way.
I wanted the unhandled target case to be treated as a fatal
error, but it turns out there's a hack in IRSymtab using
RuntimeLibcalls, which will fail out in many tests that
do not have a triple set. Many of the failures are simply
running llvm-as with no triple, which probably should not
depend on knowing an accurate set of calls.
The object file format specific derived classes are used in context
where the type is statically known. We don't use isa/dyn_cast and we
want to eliminate MCSymbol::Kind in the base class.
The object file format specific derived classes are used in context
where the type is statically known. We don't use isa/dyn_cast and we
want to eliminate MCSymbol::Kind in the base class.
The object file format specific derived classes are used in context
where the type is statically known. We don't use isa/dyn_cast and we
want to eliminate MCSymbol::Kind in the base class.
The object file format specific derived classes are used in context
where the type is statically known. We don't use isa/dyn_cast and we
want to eliminate MCSymbol::Kind in the base class.
The object file format specific derived classes are used in context
where the type is statically known. We don't use isa/dyn_cast and we
want to eliminate MCSymbol::Kind in the base class.
The object file format specific derived classes are used in context
where the type is statically known. We don't use isa/dyn_cast and we
want to eliminate MCSymbol::Kind in the base class.
Add support for the intrinsic @llvm.fptosi.sat.* and @llvm.fptoui.sat.*
- add legalizer for G_FPTOSI_SAT and G_FPTOUI_SAT
- add instructionSelector for G_FPTOSI_SAT and G_FPTOUI_SAT
- add function to add saturatedConversion decoration to the intrinsic
---------
Co-authored-by: Dmitry Sidorov <dmitry.sidorov@intel.com>
Co-authored-by: Ebin-McW <ebin.jose@multicorewareinc.com>
Co-authored-by: Michal Paszkowski <michal@michalpaszkowski.com>
Tests that checks:
- Duplicate alignment
- Duplicate types
- Non-function storage class for global variable
- Generating image instructions from opencl builtins
---------
Co-authored-by: Michal Paszkowski <michal@michalpaszkowski.com>
Fix a crash in the lifetime safety dataflow analysis when handling null CFG blocks.
Added a null check for adjacent blocks in the dataflow analysis algorithm to prevent dereferencing null pointers. This occurs when processing CFG blocks with unreachable successors or predecessors.
Original crash: https://compiler-explorer.com/z/qfzfqG5vM
Fixes https://github.com/llvm/llvm-project/issues/150095
--Test for support for specialization constant-based variable-length
--Test for ensuring that encoding of variable with undef initializer has
correct
--Test for bitreverse intrinsic with small types
--Test that verifies correct emission of OpEntryPoint and interface
variables for SPIR-V when using multiple global constants in the kernel
entry point.
--Test that verifies code generation for get_global_size() calls.
--Test that verifies SPIR-V layout and initialization of various global
variables.
The point of reentrant capabilities is that they can be acquired
multiple times, so they should probably be excluded from requiring a
negative capability on acquisition via -Wthread-safety-negative.
However, we still propagate explicit negative requirements.
This is still crashing on AIX and Solaris. It looks like maybe issues
due to trying to delete the current working directory. cd to the source
directory beforehand to try and work around that.
