We have been discussing changes to our commit access polices recently
and based on some feedback from clattner here:
https://discourse.llvm.org/t/rfc-new-criteria-for-commit-access/76290/81
We need to update our Developer Policy so that it matches what we are
actually doing in this project. We currently grant commit access to
anyone with a valid justification, not just contributors who have
submitted high-quality patches in the past.
---------
Co-authored-by: Shilei Tian <i@tianshilei.me>
…rity Group
Matthew is a member of Sony's PS4/PS5 toolchain team, most visible for
his work on LTO, but he also has a long-standing interest in security.
He will replace Paul as one of Sony's participants in the Security Group
as Paul will be retiring from Sony at the end of September.
This reverts commit 178fc4779ece31392a2cd01472b0279e50b3a199.
This attribute was not needed now that we are using the lsan style
ScopedDisabler for disabling this sanitizer
See #106736#106125
For more discussion
There is no documentation or description of the different apps in the
LLVM benchmark test-suite and this is a first attempt to document this
for the MultiSource apps.
This patch is part of a set of patches that add an `-fextend-lifetimes`
flag to clang, which extends the lifetimes of local variables and
parameters for improved debuggability. In addition to that flag, the
patch series adds a pragma to selectively disable `-fextend-lifetimes`,
and an `-fextend-this-ptr` flag which functions as `-fextend-lifetimes`
for this pointers only. All changes and tests in these patches were
written by Wolfgang Pieb (@wolfy1961), while Stephen Tozer (@SLTozer)
has handled review and merging. The extend lifetimes flag is intended to
eventually be set on by `-Og`, as discussed in the RFC
here:
https://discourse.llvm.org/t/rfc-redefine-og-o1-and-add-a-new-level-of-og/72850
This patch implements a new intrinsic instruction in LLVM,
`llvm.fake.use` in IR and `FAKE_USE` in MIR, that takes a single operand
and has no effect other than "using" its operand, to ensure that its
operand remains live until after the fake use. This patch does not emit
fake uses anywhere; the next patch in this sequence causes them to be
emitted from the clang frontend, such that for each variable (or this) a
fake.use operand is inserted at the end of that variable's scope, using
that variable's value. This patch covers everything post-frontend, which
is largely just the basic plumbing for a new intrinsic/instruction,
along with a few steps to preserve the fake uses through optimizations
(such as moving them ahead of a tail call or translating them through
SROA).
Co-authored-by: Stephen Tozer <stephen.tozer@sony.com>
Using the flag `-split_layout` in llvm-profdata merge, the output
profile can write profiles with and without inlined function into two
different extbinary sections (and their FuncOffsetTable too). The
section without inlined functions are marked with `SecFlagFlat` and is
skipped by ThinLTO because it provides no useful info.
The split layout feature was already implemented in SampleProfWriter but
previously there is no way to use it from llvm-profdata.
This patch is moving out stepvector intrinsic from the experimental
namespace.
This intrinsic exists in LLVM for several years now, and is widely used.
The previous semantics of `llvm.experimental.get.vector.length` was too
permissive such that it gave optimizers a hard time on anything related
to the number of iterations of VP-vectorized loops.
This patch tries to address this by assigning it a set of stricter
semantics similar to that of RVV's VSETVLI instructions, while being not
too RISC-V specific and leaving room for other (future) targets.
---------
Co-authored-by: Craig Topper <craig.topper@sifive.com>
The `@llvm.dx.handle.fromBinding` intrinsic is lowered either to the
`CreateHandle` op or a pair of `CreateHandleFromBinding` and `AnnotateHandle`
ops, depending on the DXIL version. Regardless of the DXIL version we need to
emit metadata about the binding, but that's left to a separate change.
These DXIL ops all need to return the `%dx.types.Handle` type, but the llvm
intrinsic returns a target extension type. To facilitate changing the type of
the operation and all of its users, we introduce `%llvm.dx.cast.handle`, which
can cast between the two handle representations.
Pull Request: https://github.com/llvm/llvm-project/pull/104251
This commit introduces emission of DebugSource, DebugCompileUnit from
NonSemantic.Shader.DebugInfo.100 and required OpString with filename.
NonSemantic.Shader.DebugInfo.100 is divided, following DWARF into two
main concepts – emitting DIE and Line.
In DWARF .debug_abbriev and .debug_info sections are responsible for
emitting tree with information (DEIs) about e.g. types, compilation
unit. Corresponding to that in NonSemantic.Shader.DebugInfo.100 have
instructions like DebugSource, DebugCompileUnit etc. which preforms same
role in SPIR-V file. The difference is in fact that in SPIR-V there are
no sections but logical layout which forces order of the instruction
emission.
The NonSemantic.Shader.DebugInfo.100 requires for this type of global
information to be emitted after OpTypeXXX and OpConstantXXX
instructions.
One of the goals was to minimize changes and interaction with
SPIRVModuleAnalysis as possible which current commit achieves by
emitting it’s instructions directly into MachineFunction.
The possibility of duplicates are mitigated by guard inside pass which
emits the global information only once in one function.
By that method duplicates don’t have chance to be emitted.
From that point, adding new debug global instructions should be
straightforward.
Substitutions can be added in a couple different ways; they can be added
via the calling python scripts by adding entries to the
config.substitutions dictionary, or via DEFINE lines in the scripts
themselves.
The substitution strings passed to Python's re classes are interpreted
so that backslashes expand to escape sequences, and literal backslashes
need to be escaped.
On Unix, the script defined substitutions don't (usually, so far)
contain backslashes - but on Windows, they often do, due to paths
containing backslashes. This lead to a Windows specific escaping of
backslashes before doing Python re substitutions - since
7c9eab8fef0ed79a5911d21eb97b6b0fa9d39f82. There's nothing inherently
Windows specific about this though - any intended literal backslashes in
the substitution strings need to be escaped; this is how the Python re
API works.
The DEFINE lines were added later, and in order to cope with
backslashes, escaping of backslashes was added in the SubstDirective
class in TestRunner, applying to DEFINE lines in the tests only.
The fact that the escaping right before passing to the Python re API was
done conditionally on Windows led to two inconsistencies:
- DEFINE lines in the tests that contain backslashes got double
backslashes on Windows. (This was visible as a FIXME in
llvm/utils/lit/tests/Inputs/shtest-define/value-escaped.txt.)
- Script provided substitutions containing backslashes did not work on
Unix, but they did work on Windows.
By removing the escaping from SubstDirective and escaping it
unconditionally in the processLine function, before feeding the
substitutions to Python's re classes, we should have consistent
behaviour across platforms, and get rid of the FIXME in the lit test.
This fixes issues with substitutions containing backslashes on Unix
platforms, as encountered in PR #86649.
Luke Wren's Hazard3 is a configurable, open-source 32-bit RISC-V core.
The core's source code and docs are available on github:
https://github.com/wren6991/hazard3
This is the RISC-V core used in the RP2350, a recently announced SoC by
Raspberry Pi (which also contains Arm cores):
https://datasheets.raspberrypi.com/rp2350/rp2350-datasheet.pdf
We have agreed to name this `-mcpu` option `rp2350-hazard3`, and it
reflects exactly the options configured in the RP2350 chips. Notably,
the Zbc is not configured, and nor is B because the `misa.B` bit is not
either.
This explicit listing of the bitcodes is out of date, and had fallen out of date in the past as well.
Delete the explicit listing and point users to where they can find it.
Another upstreaming of C API extensions we have in Julia/LLVM.jl.
Although [we went](https://github.com/maleadt/LLVM.jl/pull/431) with a
string-based API there, here I'm proposing something that's similar to
existing metadata/attribute APIs:
- explicit functions to map syncscope names to IDs, and back
- `LLVM*SyncScope` versions of builder APIs that already take a
`SingleThread` argument: atomic rmw, atomic xchg, fence
- `LLVMGetAtomicSyncScopeID` and `LLVMSetAtomicSyncScopeID` for other
atomic instructions
- testing through `llvm-c-test`'s `--echo` functionality
Verify that the arguments of a naked function are not used. They can
only be referenced via registers/stack in inline asm, not as IR values.
Doing so will result in assertion failures in the backend.
There's probably more that we should verify, though I'm not completely
sure what the constraints are (would it be correct to require that naked
functions are exactly an inline asm call + unreachable, or is more
allowed?)
Fixes https://github.com/llvm/llvm-project/issues/104718.
Propose an extension to base type DIEs such that DW_ATE_address-encoded
base types can include an architecture specific address space. Use this
to implement DW_OP_convert conversions between AMDGPU address space
addresses where meaningful.
LLVMType is both too broad and too narrow for defining DXIL operations, in
different ways. It's too broad in the sense that we don't need the full set of
MVTs - the set of types DXIL operations work on is much smaller. It's too
narrow in the sense that it's difficult to use it for the various fixed
structure types in DXIL, like `%dx.types.Handle` or `%dx.Types.ResRet.f32`.
Replace the usage of LLVMType in DXIL.td with DXILOpParamType, a simple class
that we can define an enum of types from. Further, use this to replace the
"ParameterKind" enum in DXILABI.h that has nothing to do with DXIL's ABI.
Pull Request: https://github.com/llvm/llvm-project/pull/104247
By adding a new entrypoint, `LLVMRunPassesOnFunction`, as suggested in
https://discourse.llvm.org/t/newpm-c-api-questions/80598.
Also removes erroneous `LLVMConsumeError`s from the pass builder unit
tests as the string conversion already consumes the error, causing an
abort when the test would fail.
This adds MachO support for emission of authenticated pointer
relocations.
We already support AArch64AuthMCExpr, to represent assembly expressions
such as:
.quad <symbol>@AUTH(<key>, <discriminator> [, addr])
For example:
.quad _g3@AUTH(ib, 1234, addr)
These @AUTH expressions lower to a new kind of MachO relocation:
ARM64_RELOC_AUTHENTICATED_POINTER (11)
The relocation points to the referenced symbol.
The other data, describing the signing scheme and original addend
(only 32 bits instead of 64), is encoded into the addend (in the
relocated location):
|63|62|61-51|50-49| 48 |47 - 32|31 - 0|
| 1| 0| 0 | key | addr | discriminator | addend |
Add `LLVMGetNamedFunctionWithLength` and `LLVMGetNamedGlobalWithLength`
As far as i know, it isn't currently possible to use
`LLVMGetNamedFunction` and `LLVMGetNamedGlobal` with non-null-terminated
strings.
These new functions are more convenient for C programs that use
non-null-terminated strings or for languages like Rust that primarily
use non-null-terminated strings.
This patch adds a description of the core file format used for AMDGPU.
Reference implementation for creating and loading AMDGPU core dump is
available in
[ROCgdb-6.2](https://github.com/ROCm/ROCgdb/tree/rocm-6.2.x/gdb)
C23 introduced new functions fminimum_num and fmaximum_num, and they
follow the minimumNumber and maximumNumber of IEEE754-2019. Let's
introduce new intrinsics to support them.
This patch introduces support only support for scalar values. The
support of
vector (vp, vp.reduce, vector.reduce),
experimental.constrained
will be added in future patches.
With this patch, MIPSr6 and LoongArch can work out of box with
fcanonical and fmax/fmin.
Aarch64/PowerPC64 can use the same login as MIPSr6 and LoongArch, while
they have no fcanonical support yet.
I will add it in future patches.
The FMIN/FMAX of RISC-V instructions follows the
minimumNumber/maximumNumber of IEEE754-2019. We can just add it in
future patch.
Background
https://discourse.llvm.org/t/rfc-fix-llvm-min-f-and-llvm-max-f-intrinsics/79735
Currently we have fminnum/fmaxnum, which have different behavior on
different platform for NUM vs sNaN:
1) Fallback to fmin(3)/fmax(3): return qNaN.
2) ARM64/ARM32+Neon: same as libc.
3) MIPSr6/LoongArch/RISC-V: return NUM.
And the fix of fminnum/fmaxnum to follow minNUM/maxNUM of IEEE754-2008
will submit as separated patches.
Syntacore SCR5 is an entry-level Linux-capable 32/64-bit RISC-V
processor core.
Overview: https://syntacore.com/products/scr5
Scheduling model will be added in a subsequent PR.
Co-authored-by: Dmitrii Petrov <dmitrii.petrov@syntacore.com>
Co-authored-by: Anton Afanasyev <anton.afanasyev@syntacore.com>
Fixed length vectors use scalable vector containers. With Zve32* and not
Zvl64b, vscale is a 0.5 due RVVBitsPerBlock being 64.
To support this correctly we need to lower RVVBitsPerBlock to 32 and
change our type mapping. But we need to RVVBitsPerBlock to alway be
>= ELEN. This means we need two different mapping depending on ELEN.
That is a non-trivial amount of work so disable fixed lenght vectors
without Zvl64b for now.
We had almost no tests for Zve32x without Zvl64b which is probably why
we never realized that it was broken.
Fixes#102352.
