Adds support for the SPV_INTEL_ternary_bitwise_function extension,
adding;
* the OpBitwiseFunctionINTEL SPIR-V instruction, a ternary bitwise
function where the operation performed is determined by a look-up table
index,
* and the corresponding TernaryBitwiseFunctionINTEL capability.
See
https://github.khronos.org/SPIRV-Registry/extensions/INTEL/SPV_INTEL_ternary_bitwise_function.html.
Signed-off-by: Larsen, Steffen <steffen.larsen@intel.com>
For many targets, llvm-objdump and llvm-mc
(https://reviews.llvm.org/D103004) support -M no-aliases (e.g.
`RISCVInstPrinter::applyTargetSpecificCLOption`).
This patch implements -M for llc.
While here, rename "DisassemblerOptions" in llvm-mc to the more
appropriate "InstPrinterOptions". For llvm-mc --assemble, there is no
disassembler involved.
Pull Request: https://github.com/llvm/llvm-project/pull/121078
llvm-mt requires libxml2 to work, so do not even build it without
libxml2.
CMake 3.31 and later prefer llvm-mt.exe over Microsoft's mt.exe if
available and using clang-cl.exe as CMAKE_CXX_COMPILER. When CMake picks
up llvm-mt.exe without libxml2, any build will fail with the message
```
llvm-mt: error: no libxml2
```
Any test except `--help` already uses `REQUIRES: libxml2`. There is no
point in having a non-functional executable. Not building llvm-mt.exe
will force CMake to use Microsoft's `mt.exe` instead.
Fixes: #134237
Specify the initializes attribute in terms of an "initialized" shadow
state, such that:
* Loads prior to initialization return poison.
* Bytes that are not explicitly initialized are written with undef on
function return.
This is intended to preserve the core semantics of the attribute, but
adjusts the wording in a way that is compatible with existing
optimizations, such as insertion of spurious loads and removal of
uninitialized writes.
Fixes https://github.com/llvm/llvm-project/issues/133038.
Fixes https://github.com/llvm/llvm-project/issues/133059.
Static analysis detected that Demangler::demangleStringLiteral had a
potential overflow if not checking StringByteSize properly.
Added check to ensure that for wide string it is always even and that
there were the byte count did not mismatch the actual size of the
literal.
Fixes: https://github.com/llvm/llvm-project/issues/129970
Reorder sections in GitHub.rst so that "Branches" and "Stacked Pull
Requests" appear after the more general section on pull requests. This
improves the conceptual flow for readers new to the process:
New order:
* Introduction
* Before your first PR
* Pull Requests
* Approvals
* Landing your change
* Branches
* Stacked Pull Requests
* ...
Previous order:
* Introduction
* Before your first PR
* Branches
* Stacked Pull Requests
* Pull Requests
* Approvals
* Landing your change
* ...
This change only reorders existing text - no content edits.
For 'p' the added wording matches the implementation.
For 'i', 'f', 'v' the implementation also allows 0 for `<pref>`
component, making 'i16:16:0' valid, for example. 'Fi0', 'Fn0' and 'S0'
are also currently accepted. This is likely unintentional. There are no
tests in the codebase that rely on this behavior, so the added wording
prohibits zero alignments for these specifications.
For 'a', the implementation currently allows 0 for both `<abi>` and
`<pref>` components. The added wording prohibits specifying zero for
`<pref>` with the same justification as above. Zero `<abi>` is used in
tests, and the example at the end of the section suggests that this is
valid, so that's left unchanged.
This effectively prohibits zero alignments everywhere except for the
`<abi>` component of aggregate specification.
This patch introduces a new option `-preserve-merged-debug-info` to
preserve an arbitrary but deterministic version of debug information
when DILocations are merged. This is intended to be used in production
environments from which sample based profiles are derived such as
AutoFDO and MemProf.
With this patch we have see a 0.2% improvement on an internal workload
at Google when generating AutoFDO profiles. It also significantly
improves the ability for MemProf by preserving debug info for merged
call instructions used in the contextual profile.
---------
Co-authored-by: Krzysztof Pszeniczny <kpszeniczny@google.com>
As far as I understand, the first operand of dbg_declare should be a
pointer (inside a metadata wrapper). However, using a non-pointer is
currently not rejected, and we have some tests that use non-pointer
types. As far as I can tell, these tests either meant to use dbg_value
or are just incorrect hand-crafted tests.
Ran into this while trying to `fix` #134008.
Adds code to expand the `llvm.spv.resource.handlefrombinding` and
`llvm.spv.resource.getpointer` when the resource type is
`spirv.VulkanBuffer`.
It gets expanded as a storage buffer or uniform buffer denpending on the
storage class used.
This is implementing part of
https://github.com/llvm/wg-hlsl/blob/main/proposals/0018-spirv-resource-representation.md.
The `reassoc` fast-math flag allows a much wider array of algebraic
transformations than just strictly reassociations. In some cases it does
commutations, distributions, and folds away redundant inverse
operations...
While it might make sense to fix the flag naming at some point, in the
meantime we should at least have the docs be accurate to avoid
confusion.
This makes it easier to reduce llvm-reduce with llvm-reduce to filter
cases where the input reduced too much.
Not sure if it's possible to test the exit code in lit.
During the transition from debug intrinsics to debug records, we used
several different command line options to customise handling: the
printing of debug records to bitcode and textual could be independent of
how the debug-info was represented inside a module, whether the
autoupgrader ran could be customised. This was all valuable during
development, but now that totally removing debug intrinsics is coming
up, this patch removes those options in favour of a single flag
(experimental-debuginfo-iterators), which enables autoupgrade, in-memory
debug records, and debug record printing to bitcode and textual IR.
We need to do this ahead of removing the
experimental-debuginfo-iterators flag, to reduce the amount of
test-juggling that happens at that time.
There are quite a number of weird test behaviours related to this --
some of which I simply delete in this commit. Things like
print-non-instruction-debug-info.ll , the test suite now checks for
debug records in all tests, and we don't want to check we can print as
intrinsics. Or the update_test_checks tests -- these are duplicated with
write-experimental-debuginfo=false to ensure file writing for intrinsics
is correct, but that's something we're imminently going to delete.
A short survey of curious test changes:
* free-intrinsics.ll: we don't need to test that debug-info is a zero
cost intrinsic, because we won't be using intrinsics in the future.
* undef-dbg-val.ll: apparently we pinned this to non-RemoveDIs in-memory
mode while we sorted something out; it works now either way.
* salvage-cast-debug-info.ll: was testing intrinsics-in-memory get
salvaged, isn't necessary now
* localize-constexpr-debuginfo.ll: was producing "dead metadata"
intrinsics for optimised-out variable values, dbg-records takes the
(correct) representation of poison/undef as an operand. Looks like we
didn't update this in the past to avoid spurious test differences.
* Transforms/Scalarizer/dbginfo.ll: this test was explicitly testing
that debug-info affected codegen, and we deferred updating the tests
until now. This is just one of those silent gnochange issues that get
fixed by RemoveDIs.
Finally: I've added a bitcode test, dbg-intrinsics-autoupgrade.ll.bc,
that checks we can autoupgrade debug intrinsics that are in bitcode into
the new debug records.
Since lldb 20, these have had no effect:
https://releases.llvm.org/20.1.0/docs/ReleaseNotes.html#changes-to-lldb
> lldb-server now listens to a single port for gdbserver connections and
> provides that port to the connection handler processes. This means
that
> only 2 ports need to be opened in the firewall (one for the
lldb-server
> platform, one for gdbserver connections). In addition, due to this
work,
lldb-server now works on Windows in the server mode.
Remove them.
This adds DWARF generation for fixed-point types. This feature is needed
by Ada.
Note that a pre-existing GNU extension is used in one case. This has
been emitted by GCC for years, and is needed because standard DWARF is
otherwise incapable of representing these types.
This extension adds two external input output instructions for
non-memory-mapped device.
The current spec can be found at:
https://github.com/quic/riscv-unified-db/releases/tag/Xqci-0.7.0
This patch adds assembler only support.
Co-authored-by: Sudharsan Veeravalli <quic_svs@quicinc.com>
If the interestingness script is flaky, we should not assert. Print
a warning, and continue. This could still happen as a result of an
llvm-reduce bug, so make a note of that.
Add a --skip-verify-interesting-after-counting-chunks option to
avoid the extra run of the reduction script, and to silence the
warning.
I put the documentation of all factors into the same (de)interleave
entries because I really don't see a reason to separate them in an
already long LangRef page.
I would like to nominate Mario Cupelli (@mariocup) and myself to join
the LLVM Security Group as representatives (vendor contacts) of [HighTec
EDV Systeme](https://github.com/hightec-rt).
Mario is the CTO of HighTec and has a strong background in compiler
safety qualification. I am a SW engineer with a focus on cybersecurity
and a goal to contribute to the LLVM Security Group.
HighTec collaborates with major silicon vendors and offers
safety-qualified C/C++ and Rust compilers based on LLVM. Our active
contributions to LLVM include work on the linker and various patches and
we are committed to further improving LLVM’s security.
Our motivation for joining the LLVM Security Group is to collaborate
with LLVM security experts, stay informed about the latest CVEs in LLVM
and meet the cybersecurity requirements of the automotive industry.
The format is: `!instances<T>([regex])`.
This operator produces a list of records whose type is `T`. If
`regex` is provided, only records whose name matches the regular
expression `regex` will be included. The format of `regex` is ERE
(Extended POSIX Regular Expressions).
This implements [the `.option exact` and `.option noexact`
proposal](https://github.com/riscv-non-isa/riscv-asm-manual/pull/122)
for RISC-V.
`.option exact` turns off:
- Compression
- Branch Relaxation
- Linker Relaxation
`.option noexact` turns these back on, and is also the default, matching
the current behaviour.
The link should refer to the section of 'phi' Instruction in the
LangRef, but it referred to the subsection of 'fcmp' Instruction.
Replace it with appropriate one.
In Ada, an array can be packed and the elements can take less space than
their natural object size. For example, for this type:
type Packed_Array is array (4 .. 8) of Boolean;
pragma pack (Packed_Array);
... each element of the array occupies a single bit, even though the
"natural" size for a Boolean in memory is a byte.
In DWARF, this is represented by putting a DW_AT_bit_stride onto the
array type itself.
This patch adds a bit stride to DICompositeType so that gnat-llvm can
emit DWARF for these sorts of arrays.
Option becomes: -instruction-tables=`<level>`
The choice of `<level>` controls number of printed information.
`<level>` may be `none` (default), `normal`, `full`.
Note: If the option is used without `<label>`, default is `normal`
(legacy).
When `<level>` is `full`, additional information are:
- `<Bypass Latency>`: Latency when a bypass is implemented between
operands
in pipelines (see SchedReadAdvance).
- `<LLVM Opcode Name>`: mnemonic plus operands identifier.
- `<Resources units>`: Used resources associated with LLVM Opcode.
- `<instruction comment>`: reports comment if any from source assembly.
Level `full` can be used to better check scheduling info when TableGen
is modified.
LLVM Opcode name help to find right instruction regexp to fix TableGen
Scheduling Info.
-instruction-tables=full option is validated on
AArch64/Neoverse/V1-sve-instructions.s
Follow up of MR #126703
---------
Co-authored-by: Julien Villette <julien.villette@sipearl.com>
This is required to support `li`, but the code is also shared with
CodeGen so the compiler will now emit instructions from Xqcili when that
extension is enabled during compilation.
Also implemented some missed verifiers in
`RISCVInstrInfo::verifyInstruction`, some of which are required for this
change.
According to the shader manual there are not buffer load lds
instructions of gfx11.
The tests for the regular `buffer_load ... lds` instructions for gfx11
are already present in AMDGPU/gfx11_asm_mubuf.s, where the compiler
fails to encode the instructions for this target.
When a developer copy/pastes a failing command line into their
shell to rerun it, they have to manually delete the "RUN: at line
N:" prefix. To make life easier for such developers, let's make it
possible to copy/paste a command without needing to modify it while
still showing the line number in the output by moving the line number
to a comment at the end of the command line.
Reviewers: jroelofs, MaskRay
Reviewed By: jroelofs, MaskRay
Pull Request: https://github.com/llvm/llvm-project/pull/132485
With a minor fix for the build failures.
Original message:
This extension adds nine instructions, eight for non-memory-mapped devices synchronization and delay instruction.
The current spec can be found at:
https://github.com/quic/riscv-unified-db/releases/tag/Xqci-0.7.0
This patch adds assembler only support.
Co-authored-by: Sudharsan Veeravalli quic_svs@quicinc.com
This extension adds nine instructions, eight for non-memory-mapped
devices synchronization and delay instruction.
The current spec can be found at:
https://github.com/quic/riscv-unified-db/releases/tag/Xqci-0.7.0
This patch adds assembler only support.
Co-authored-by: Sudharsan Veeravalli <quic_svs@quicinc.com>
Set the default processor version to v68 when the user does not specify
one in the command line. This includes changes in the LLVM backed and
linker (lld). Since lld normally sets the version based on inputs, this
change will only affect cases when there are no inputs.
Fixes#127558
There should be no substantial policy change here.
I reordered the breaking change docs after the major change docs, since
that flow made sense to me. I smoothed out some of the incremental
development policy wording to be a bit less black and white, and talk
about "preferred" and "discouraged" approaches.
The i6400 and i6500 are high performance multi-core microprocessors from
MIPS that provide best in class power efficiency for use in
system-on-chip (SoC) applications. i6400 and i6500 implements Release 6
of the MIPS64 Instruction Set Architecture with full hardware
multithreading and hardware virtualization support.
