Simplifies the implementation of `TypeSize` while retaining its interface.
There is no need for abstract concepts like `LinearPolyBase`, `UnivariateLinearPolyBase` or `LinearPolySize`.
Differential Revision: https://reviews.llvm.org/D140263
Simplifies the implementation of `TypeSize` while retaining its interface.
There is no need for abstract concepts like `LinearPolyBase`, `UnivariateLinearPolyBase` or `LinearPolySize`.
Differential Revision: https://reviews.llvm.org/D140263
Use deduction guides instead of helper functions.
The only non-automatic changes have been:
1. ArrayRef(some_uint8_pointer, 0) needs to be changed into ArrayRef(some_uint8_pointer, (size_t)0) to avoid an ambiguous call with ArrayRef((uint8_t*), (uint8_t*))
2. CVSymbol sym(makeArrayRef(symStorage)); needed to be rewritten as CVSymbol sym{ArrayRef(symStorage)}; otherwise the compiler is confused and thinks we have a (bad) function prototype. There was a few similar situation across the codebase.
3. ADL doesn't seem to work the same for deduction-guides and functions, so at some point the llvm namespace must be explicitly stated.
4. The "reference mode" of makeArrayRef(ArrayRef<T> &) that acts as no-op is not supported (a constructor cannot achieve that).
Per reviewers' comment, some useless makeArrayRef have been removed in the process.
This is a follow-up to https://reviews.llvm.org/D140896 that introduced
the deduction guides.
Differential Revision: https://reviews.llvm.org/D140955
Revert "Fix lldb option handling since e953ae5bbc (part 2)"
Revert "Fix lldb option handling since e953ae5bbc313fd0cc980ce021d487e5b5199ea4"
GCC build hangs on this bot https://lab.llvm.org/buildbot/#/builders/37/builds/19104
compiling CMakeFiles/obj.clangBasic.dir/Targets/AArch64.cpp.d
The bot uses GNU 11.3.0, but I can reproduce locally with gcc (Debian 12.2.0-3) 12.2.0.
This reverts commit caa713559b.
This reverts commit 06b90e2e9c.
This reverts commit e953ae5bbc.
RISCV build and tests are often broken.
You can use `llvm_targets_to_build = "experimental"` to enable
_all_ targets, including the experimental ones. If RISCV is listed
in llvm_targets_to_build, it's built as before.
This diff was generated by the following script:
#!/usr/bin/env python3
import os, subprocess
r = subprocess.run('git show --pretty='' --name-only f09cf34d00'.split(),
stdout=subprocess.PIPE, text=True)
for line in r.stdout.splitlines():
if not line.endswith('CMakeLists.txt'): continue
gn = 'llvm/utils/gn/secondary/' + os.path.dirname(line) + '/BUILD.gn'
if not os.path.exists(gn): continue
with open(gn) as f:
contents = f.read()
if contents.count('"//llvm/lib/Support",') == 1:
contents = contents.replace(
'"//llvm/lib/Support",',
'"//llvm/lib/Support", "//llvm/lib/TargetParser",')
elif contents.count(' deps = [') == 1:
contents = contents.replace(
' deps = [',
' deps = [ "//llvm/lib/TargetParser",')
else:
print('needs manual fixup:', gn)
continue
with open(gn, 'w') as f:
f.write(contents)
I then manually fixed up the BUILD.gn files for Support (should not depend on
TargetParser) and TargetParser (should depend on Support) and ran `gn format`
on all touched files.
Allow targets to define a mapping from registers to register
classes such that each register has exactly one base class.
As registers may be in multiple register classes the base class
is determined by the container class with the lowest BaseClassOrder.
Only register classes with BaseClassOrder set are considered
when determining the base classes. By default BaseClassOrder is
unset in RegisterClass so no code is generated unless a target
explicit defines one or more base register classes.
Reviewed By: arsenm, foad
Differential Revision: https://reviews.llvm.org/D139616
