| Age | Commit message (Collapse) | Author |
|---|
|
`std.Target`: Remove `minix` and `liteos`, rename `glsl450` to `opengl`, and some minor housekeeping
|
|
https://github.com/llvm/llvm-project/issues/50374
|
|
https://github.com/llvm/llvm-project/blob/efc6b50d2d93fa571572ee3ef1d4565c09ad1610/llvm/lib/Target/Sparc/SparcISelLowering.cpp#L561-L562
|
|
This makes it clearer which OSs are not known to or supported by LLVM at all vs
the ones where we're intentionally passing choosing "unknown".
|
|
It has not seen development in 4 years.
https://github.com/LiteOS/LiteOS/commits/master
|
|
It has not seen development in 6 years. RIP.
* https://github.com/Stichting-MINIX-Research-Foundation/minix/commits/master
* https://groups.google.com/g/minix3/c/nUG1NwxXXkg
|
|
Versions can simply use the normal version range mechanism, or alternatively an
Abi tag if that makes more sense. For now, we only care about 4.5 anyway.
|
|
Follow-up on `std.Target` GPU changes in #20960
|
|
Eliding the namespace when a container type has no decls was an
experiment in saving memory, but it ended up causing more trouble than
it was worth in various places. So, take the small memory hit for
reified types, and just give every container type a namespace.
|
|
The type `Zcu.Decl` in the compiler is problematic: over time it has
gained many responsibilities. Every source declaration, container type,
generic instantiation, and `@extern` has a `Decl`. The functions of
these `Decl`s are in some cases entirely disjoint.
After careful analysis, I determined that the two main responsibilities
of `Decl` are as follows:
* A `Decl` acts as the "subject" of semantic analysis at comptime. A
single unit of analysis is either a runtime function body, or a
`Decl`. It registers incremental dependencies, tracks analysis errors,
etc.
* A `Decl` acts as a "global variable": a pointer to it is consistent,
and it may be lowered to a specific symbol by the codegen backend.
This commit eliminates `Decl` and introduces new types to model these
responsibilities: `Cau` (Comptime Analysis Unit) and `Nav` (Named
Addressable Value).
Every source declaration, and every container type requiring resolution
(so *not* including `opaque`), has a `Cau`. For a source declaration,
this `Cau` performs the resolution of its value. (When #131 is
implemented, it is unsolved whether type and value resolution will share
a `Cau` or have two distinct `Cau`s.) For a type, this `Cau` is the
context in which type resolution occurs.
Every non-`comptime` source declaration, every generic instantiation,
and every distinct `extern` has a `Nav`. These are sent to codegen/link:
the backends by definition do not care about `Cau`s.
This commit has some minor technically-breaking changes surrounding
`usingnamespace`. I don't think they'll impact anyone, since the changes
are fixes around semantics which were previously inconsistent (the
behavior changed depending on hashmap iteration order!).
Aside from that, this changeset has no significant user-facing changes.
Instead, it is an internal refactor which makes it easier to correctly
model the responsibilities of different objects, particularly regarding
incremental compilation. The performance impact should be negligible,
but I will take measurements before merging this work into `master`.
Co-authored-by: Jacob Young <jacobly0@users.noreply.github.com>
Co-authored-by: Jakub Konka <kubkon@jakubkonka.com>
|
|
`llvm`: Fix hasLlvmSupport() for dxil, spirv[32,64], and kalimba.
|
|
|
|
|
|
|
|
|
|
* Rename isPPC() -> isPowerPC32().
* Rename isPPC64() -> isPowerPC64().
* Add new isPowerPC() function which covers both.
There was confusion even in the standard library about what isPPC() meant. This
change makes these functions work how I think most people actually expect them
to work, and makes them consistent with isMIPS(), isSPARC(), etc.
I chose to rename from PPC to PowerPC because 1) it's more consistent with the
other functions, and 2) it'll cause loud rather than silent breakage for anyone
who might have been depending on isPPC() while misunderstanding it.
|
|
It's discontinued in favor of WASI.
https://github.com/NuxiNL/cloudlibc
|
|
This is a fairly small hobby OS that has not seen development in 2 years. Our
current policy is that hobby OSs should use the `other` tag.
https://github.com/zhmu/ananas
|
|
What is `sparcel`, you might ask? Good question!
If you take a peek in the SPARC v8 manual, §2.2, it is quite explicit that SPARC
v8 is a big-endian architecture. No little-endian or mixed-endian support to be
found here.
On the other hand, the SPARC v9 manual, in §3.2.1.2, states that it has support
for mixed-endian operation, with big-endian mode being the default.
Ok, so `sparcel` must just be referring to SPARC v9 running in little-endian
mode, surely?
Nope:
* https://github.com/llvm/llvm-project/blob/40b4fd7a3e81d32b29364a1b15337bcf817659c0/llvm/lib/Target/Sparc/SparcTargetMachine.cpp#L226
* https://github.com/llvm/llvm-project/blob/40b4fd7a3e81d32b29364a1b15337bcf817659c0/llvm/lib/Target/Sparc/SparcTargetMachine.cpp#L104
So, `sparcel` in LLVM is referring to some sort of fantastical little-endian
SPARC v8 architecture. I've scoured the internet and I can find absolutely no
evidence that such a thing exists or has ever existed. In fact, I can find no
evidence that a little-endian implementation of SPARC v9 ever existed, either.
Or any SPARC version, actually!
The support was added here: https://reviews.llvm.org/D8741
Notably, there is no mention whatsoever of what CPU this might be referring to,
and no justification given for the "but some are little" comment added in the
patch.
My best guess is that this might have been some private exercise in creating a
little-endian version of SPARC that never saw the light of day. Given that SPARC
v8 explicitly doesn't support little-endian operation (let alone little-endian
instruction encoding!), and no CPU is known to be implemented as such, I think
it's very reasonable for us to just remove this support.
|
|
These were for very old OpenCL have been long abandoned in favor of SPIR-V.
* https://github.com/KhronosGroup/SPIR
* https://github.com/KhronosGroup/SPIR-Tools
|
|
This is a misfeature that we inherited from LLVM:
* https://reviews.llvm.org/D61259
* https://reviews.llvm.org/D61939
(`aarch64_32` and `arm64_32` are equivalent.)
I truly have no idea why this triple passed review in LLVM. It is, to date, the
*only* tag in the architecture component that is not, in fact, an architecture.
In reality, it is just an ILP32 ABI for AArch64 (*not* AArch32).
The triples that use `aarch64_32` look like `aarch64_32-apple-watchos`. Yes,
that triple is exactly what you think; it has no ABI component. They really,
seriously did this.
Since only Apple could come up with silliness like this, it should come as no
surprise that no one else uses `aarch64_32`. Later on, a GNU ILP32 ABI for
AArch64 was developed, and support was added to LLVM:
* https://reviews.llvm.org/D94143
* https://reviews.llvm.org/D104931
Here, sanity seems to have prevailed, and a triple using this ABI looks like
`aarch64-linux-gnu_ilp32` as you would expect.
As can be seen from the diffs in this commit, there was plenty of confusion
throughout the Zig codebase about what exactly `aarch64_32` was. So let's just
remove it. In its place, we'll use `aarch64-watchos-ilp32`,
`aarch64-linux-gnuilp32`, and so on. We'll then translate these appropriately
when talking to LLVM. Hence, this commit adds the `ilp32` ABI tag (we already
have `gnuilp32`).
|
|
|
|
Before, this code:
@setRuntimeSafety(false);
var arr: [38]elf.Addr = undefined;
would emit a call to memset() in the output code in Debug mode, while in all the
release modes, LLVM optimized the memset() out as expected. Emitting the call in
Debug mode is problematic in some contexts, e.g. in std.os.linux.start_pie where
we are not yet ready to correctly perform calls because relocations haven't been
applied yet, or in the early stages of a dynamic linker, etc.
|
|
* Add -f(no-)sanitize-coverage-trace-pc-guard CLI flag which defaults to
off. This value lowers to TracePCGuard = true (LLVM backend) and -Xclang
-fsanitize-coverage-trace-pc-guard. These settings are not
automatically included with -ffuzz.
* Add `Build.Step.Compile` flag for sanitize_coverage_trace_pc_guard
with appropriate documentation.
* Add `zig cc` integration for the respective flags.
* Avoid crashing in ELF linker code when -ffuzz -femit-llvm-ir used
together.
|
|
Exposes sanitizer coverage flags to the target machine emit function.
Makes it easier to change sancov options without rebuilding the C++
files.
This also enables PCTable = true for sancov which is needed by AFL, and
adds the corresponding Clang flag.
|
|
This is needed to ensure that start code does not try to access thread
local storage before it has set up thread local storage.
|
|
* Add the `-ffuzz` and `-fno-fuzz` CLI arguments.
* Detect fuzz testing flags from zig cc.
* Set the correct clang flags when fuzz testing is requested. It can be
combined with TSAN and UBSAN.
* Compilation: build fuzzer library when needed which is currently an
empty zig file.
* Add optforfuzzing to every function in the llvm backend for modules
that have requested fuzzing.
* In ZigLLVMTargetMachineEmitToFile, add the optimization passes for
sanitizer coverage.
* std.mem.eql uses a naive implementation optimized for fuzzing when
builtin.fuzz is true.
Tracked by #20702
|
|
It is very non-obvious that this is what lv2 refers to, and we already use ps4
and ps5 to refer to the later models, so let's just be consistent.
|
|
There is no obvious reason why this would be relevant for Zig to target. I
rather question the value of LLVM even having target triple code for this, too.
See: https://blog.llvm.org/2010/06/tce-project-co-design-of-application.html
See: https://github.com/cpc/llvmtce
|
|
This was added as an architecture to LLVM's target triple parser and the Clang
driver in 2015. No backend ever materialized as far as I can see (same for GCC).
In 2016, other code referring to it started using "Myriad" instead. Ultimately,
all code related to it that isn't in the target triple parser was removed. It
seems to be a real product, just... literally no one seems to know anything
about the ISA. I figure after almost a decade with no public ISA documentation
to speak of, and no LLVM backend to reference, it's probably safe to assume that
we're not going to learn much about this ISA, making it useless for Zig.
See: https://github.com/llvm/llvm-project/commit/1b5767f72b5a037ca8f1802d737de97f8d92263d
See: https://github.com/llvm/llvm-project/commit/84a7564b28360843ee9afec5d3823c89623eb6a5
See: https://github.com/llvm/llvm-project/commit/8cfe9d8f2ad3a52ba7fd5841d3939aa810536e16
|
|
This seems to just be dead.
See: https://github.com/search?q=repo%3Allvm%2Fllvm-project%20hsail&type=code
See: https://github.com/HSAFoundation/HSAIL-Tools/commits/master
|
|
This is really obscure and no one is 100% sure what it is. It seems to be old
and unused. My suspicion is that it's just an old term for "AMDGPU" before it
was upstreamed to LLVM.
See: https://github.com/search?q=repo%3Allvm%2Fllvm-project+amdil&type=code
|
|
These are quite old GPUs, and it is unlikely that Zig will ever be able to
target them.
See: https://en.wikipedia.org/wiki/Radeon_HD_2000_series
|
|
It's dead: https://developer.android.com/guide/topics/renderscript/migrate
|
|
This reverts commit 397be0c9cc8156d38d1487a4c80210007033cbd0, reversing
changes made to 18d412ab2fb7bda92f7bfbdf732849bbcd066c33.
Caused test failures in master branch.
|
|
|
|
llvm: Nest debug info correctly
|
|
std.Target: Remove some obsolete/dead specifiers.
|
|
|
|
|
|
|
|
This was added to LLVM in 2015 for the LLILC project, which was discontinued in
~2018, and subsequently archived in 2022.
https://github.com/dotnet/llilc/commit/933b58d00ffb4b357956c940b37a379bdf891324
|
|
Native Client is dead.
https://developer.chrome.com/docs/native-client
|
|
kFreeBSD is dead.
https://lists.debian.org/debian-devel/2023/07/msg00176.html
|
|
This was used for LoongArch64, where:
* `gnuf64` -> `ilp32d` / `lp64d` (full hard float)
* `gnuf32` -> `ilp32f` / `lp64f` (hard float for `f32` only)
* `gnusf` -> `ilp32` / `lp64` (soft float)
But Loongson eventually settled on just `gnu` for the first case since that's
what most people will actually be targeting outside embedded scenarios. The
`gnuf32` and `gnusf` specifiers remain in use.
|
|
Without this data, debugger expressions try to pass structs by-value,
which mostly just crashes.
Also: mark enums as enum classes to prevent the enumerators from
shadowing other identifiers.
|
|
They were not helping LLDB and actively throwing off GDB.
Also: clean up some llvm.Builder and llvm.ir definitions that are no
longer necessary.
|
|
This does not help anything though: gdb would follow the
DW_AT_specification link only in the opposite direction, which LLVM
cannot emit.
|
|
|
|
Add a regression test for that, since these weirdly never occur in any
of the other tests on x86-64-linux.
|
