https://github.com/EmbarkStudios/rust-gpu/blob/75ca54546b6b1e6de753040ced4749835dc33e11/rustc_codegen_spirv/src/codegen_cx/constant.rs#L408 asserts that padding bytes are undef while at the same type padding bytes of contained types are not undef. Neither has to be true.

LLVM doesn't have a tan intrinsic, unlike all the other methods here.

copysign can be implemented using bit manipulation. I think the following will work:

f32::from_bits((this.to_bits() & (u32::max_value() >> 1)) | (sign.to_bits() & (1 << 31)))

I think what happens is because of the + {error} the question if it implements FnOnce results in an ambiguous solution. This will then cause impls_fnonce to return true, as solution.is_some() is true.

The Callable modifier comes from https://github.com/rust-analyzer/rust-analyzer/blob/35ed3d2c005fdb0ec9ab78a52b31758bd7de298e/crates/ide/src/syntax_highlighting.rs#L773-L775

glam uses the sqrt function implemented by libstd. This function calls into libm. The easiest way would be to intercept this call. It has a known symbol name.

I think DefId should completely be avoided in the input of the linker function. One of the uses if NativeLib in it's foreign_module field. This field doesn't seem to be used by the linking code.

I've removed unused imports!

nit: missing trailing newline

nit: missing trailing newline

What about naming it no_asm instead? That makes it clear that it isn't just for cg_clif, as other backends may also not support inline asm.

@rustbot modify labels: -S-waiting-on-author +S-waiting-on-review

Cranelift only uses region::page::size and region::protect. Adding a feature flag for the querying abilities would also be nice for Redox OS.

It took me a while to wrap my head around this, but what happens is the following: The i % WIDTH generates an x coordinate in the range 0..WIDTH, the / WIDTH turns it into the range 0.0 .. 1.0, the * 2.0 - 1.0 then turns it into the range -1.0 .. 1.0. Same for the y coordinate.

Once https://github.com/rust-lang/rust/pull/77975 lands Mode::Codegen shouldn't use this. Also for executables the linker will rewrite it anyway.

Squashed into cf798c1ec65a5ec3491846777f9003fabb881b4a and added subtree in ac4f7deb2f3558d2d923fa6ddcbb7210db9c2d52.

I found -z nodlopen, but it doesn't seem to affect tls storage model. By the way instead of mode != Mode::Std I think it should be mode == Mode::Rustc, so other things don't accidentally get the initial-exec TLS storage model.

Regression of up to 3%.

It should be possible to intercept calls to functions with specific names and instead emit a SPIRV instruction.

libstd directly calls the libm functions. Adding an extra intrinsic requires a rustc change to add it to the list of intrinsics of typeck.

Wouldn't rustup component add rust-src rustc-dev llvm-tools-preview automatically install the correct nightly?

That is a duplicate of https://github.com/rust-analyzer/rust-analyzer/issues/6038.

cg_clif has a script that will update rust-toolchain for the latest version, does a cargo clean and remove all old nightly versions at the same time. It also supports commiting with a commit message stating the new rustc version. It may be useful https://github.com/bjorn3/rustc_codegen_cranelift/blob/8ec977e763baee45dbc6b3efd84e96a7e5dc3f91/scripts/rustup.sh (It uses the local time to select the right rustc version, so it may not work of you are not in Europe)

                                    Applicability::MachineApplicable,

This preserves the original meaning, even if it may not have been the intended one.

For dylibs there is a separate codegen unit for metadata. You can add the symbol there. For executables you can add it to the main shim generation. For rlibs you can add a separate archive member.

You should not pass -C target-cpu=native when running cargo test.

So I guess it's all working fine but some optimisation layer is removing it (linker maybe?). I will try and see if I can hint to the linker not to remove it...

This for executables? You may need to do the same as for the gdb debug scripts section. (reference it from the main shim using a volatile load)

https://github.com/rust-lang/rust/blob/17cc9b6256c95c31944591aec683884fead4e3b6/compiler/rustc_codegen_ssa/src/base.rs#L429

This needs to be crate_hash. crate_disambiguator is passed by cargo using -Cmetadata and doesn't depend on the source code.

Mesa has support for software rendering using the llvmpipes backend. It should be possible to use this for testing.

nit: missing trailing newline

Huge wins of up to 35% in incremental mode. Slight regression of up to 0.5% in non-incremental mode.

The three return value case is an extension of the System-V abi, it only gives a verifier error for four or more return values. While this extension is supported by both Cranelift and I think LLVM, it will never be used for #[repr(C)] structs with three register sized elements, as that would be in conflict with the System-V abi. I am pretty sure there is no way to convince rustc to use this extension. You should instead just take an extra argument that points to a place to write the return value to.

We are currently in the process of switching to a new framework for backends. I am not quite sure what has already been implemented in the new backends and what hasn't.

lazy_static! creates a type named the same as the static. It uses #[allow(non_camel_case_types)] to suppress the warning for rustc, but rust-analyzer doesn't have support for this.

Also using multiple return values to represent returning a tuple struct is not correct in the general case. For the two primitive elements case it happens to be correct on x86_64 with the System-V call conv, but for three or more elements the function in most cases actually takes a pointer to where the struct needs to be stored.

It isn't allowed to return more than 3 values. This should result in an error when you run the verifier.

Slight regression up to 0.6%.

Maybe use #![cfg_attr(target_arch = "spirv"), no_std] at https://github.com/EmbarkStudios/rust-gpu/blob/8681464af7e2500f371e5df6a95691cf29ecd16a/spirv-std/src/lib.rs#L1

That will ensure that any linked dylib will have all dependencies required for the target triple.

Is it accidentally trying to compile the shader for the host too?

You should be able to avoid this if you pass -Cpanic=abort to rustc.

    "examples/wgpu-example-runner",

nit: you used a tab instead of four spaces like the rest of this file.

There are intrinsics for the unordered versions of atomic operations, but they aren't used by Atomic*.

You don't need a zombie here. exactudiv is the same as udiv except that it is UB when there is a remainder and in a few other cases. It is fine to just ignore the UB. You may want to add a FIXME to take advantage of the UB in the future.

@and-arch You are listed in the watch list of this repo. If you don't want to get emails for notifications on this repo, you should unwatch it. On the top left corner of all pages of this repo there are three buttons. One to watch/unwatch, one to star/unstar and one to fork.

It is simpler to directly return the zombie here I think.

This is a slight speedup.

You will need to add the following to Cargo.toml I think:

[profile.bench]
debug = false

If you tell the linker about the storage model instead of LLVM it should rewrite all TLS accesses to use that storage model I think. You could do that using a build.rs for rustc_driver. That will apply it to exactly the dylib that it should be applied to.

https://doc.rust-lang.org/nightly/nightly-rustc/rustc_session/struct.Session.html#method.check_name

The docs say that tools shouldn't use it, but that was probably written when #![register_attr] didn't exist yet.

In PM @khyperia said this doesn't work as the lint is fired before the codegen backend runs.

https://doc.rust-lang.org/nightly/nightly-rustc/rustc_session/struct.Session.html#method.check_name

The docs say that tools shouldn't use it, but that was probably written when #![register_attr] didn't exist yet.

https://github.com/EmbarkStudios/rust-gpu/blob/f4f103197694290c469ad00d8f156ea7d0bfc292/rustc_codegen_spirv/src/builder/builder_methods.rs#L55-L67

According to https://www.khronos.org/blog/comparing-the-vulkan-spir-v-memory-model-to-cs the following must change:

• Acquire must use MakeVisible | Acquire
• Release must use MakeAvailable | Release
• AcqRel must use MakeAvailable | MakeVisible | AcquireRelease
• According to the SPIR-V specification SeqCst must not be used for Vulkan. https://www.khronos.org/registry/spir-v/specs/unified1/SPIRV.html#_a_id_memory_semantics__id_a_memory_semantics_lt_id_gt

  If the declared memory model is Vulkan, SequentiallyConsistent must not be used.

For example saturating_add isn't implemented in a saturating way:

https://github.com/EmbarkStudios/rust-gpu/blob/f4f103197694290c469ad00d8f156ea7d0bfc292/rustc_codegen_spirv/src/builder/intrinsics.rs#L88-L97

This is more of a lesson I learnt the hard way than an issue with rust-gpu itself. While it may seem like a good idea at first to get it quickly working, it will backfire in the long term. I have spent quite a lot of time debugging miscompilations in cg_clif caused by exactly this kind of shortcuts. At minimum I think you should add a FIXME every time you add such a shortcut.

I think watchos and all other operating systems of apple should be included too.

Would this allow us to write integration tests against an exe? Currently we can only do it against libs. (I.e. tests in the tests dir). This leads to a lot of exes being changed into libs just for test purposes...

That would require including crate metadata in the executable. This may also be useful for Headcrab to compile rust code against the debugged executable and inject it. for a counter to the print command of gdb and lldb that accepts arbitrary rust code. DWARF debuginfo doesn't provide enough information for arbitrary rust code. Only for the tiny subset of rust that gdb and lldb accept.

For iOS it may or may not work to extend the condition at https://github.com/rust-lang/backtrace-rs/blob/8eee2e473e71e659cbd5d32ee78aaf42e8b75752/src/symbolize/gimli.rs#L204 to include iOS too.

Likely caused by #74682. (switching from libbacktrace to gimli)

It seems that native_libraries is not implemented for FreeBSD: https://github.com/rust-lang/backtrace-rs/blob/8eee2e473e71e659cbd5d32ee78aaf42e8b75752/src/symbolize/gimli.rs#L435-L436 I think this means that it can't find the debuginfo for any libraries and the current executable.

Yes, I get a notification for a failed pr labeler cronjob on my wasmtime fork every so often. https://github.com/bjorn3/wasmtime/actions?query=is%3Afailure

I enabled both web and email notifications for failed github actions runs. I haven't ever had a problem with it. Maybe it has to do something with miri being part of an organization, while cg_clif is part of my user. I haven't ever got a notification for rust-analyzer either. I am a triage team member and I am watching the main rust-analyzer repo.

macOS has both DWARF unwinding and compact unwind info. Both of which can be used with the same SystemV calling convention.

const INPUT_ONE: () = ();
const INPUT_TWO: () = ();

pub fn func((INPUT_ONE, INPUT_TWO): ((), ())) {}

is valid rust and doesn't give a warning with rustc either. INPUT_ONE and INPUT_TWO match () here. This means that implementing this lint in this case will have to resolve identifiers, which can slow it down and will give spurious warnings on incomplete code elsewhere.

The textmate grammar was introduced to minimize the difference in syntax highlighting before and after semantic highlighting takes effect.

https://github.com/rust-lang/rustc-perf/blob/056d7a2bbdeaf1e23d598a9548ccf3c3f68c15c9/collector/benchmarks/ctfe-stress-4/src/lib.rs

ctfe-stress-4 uses const fn which behaves similar to #[inline] I think.

The slight slowdowns don't reflect in the self-profile data, so I don't know where they're coming from.

I saw eval_to_allocation_raw for ctfe-stress-4.

roblox is not a minimal GUI app.

stty sane enables BRKINT. Also with a shell I am not only referring to something like bash, but also repls like python, node, gdb, ...

                panic!("Could not find token in GITHUB_API_TOKEN or .gitconfig/github.oauth-token")

On Windows a system library is used. Because miri doesn't perform any linking, it is fine if that system library turns out to be missing. For unix backtrace-rs used to use libbacktrace, which gets compiled in build.rs, thus requiring a C toolchain for the target platform. Since the switch to gimli it only depends on libunwind for unwinding, which is a system library and also not used for miri anyway.

(Or does it avoid even linking in the debug symbol parsing when Miri is used?)

The debuginfo handling has been replaced by addr2line on non-Windows systems by default for a while now. (https://github.com/rust-lang/backtrace-rs/pull/324) One of the reasons for this switch was:

Secondarily, it means this library no longer needs a C compiler. Being an all-Rust crate generally makes it much easier to cross-compile, port, etc.

Currently many instructions are both scalar and vector instructions at the same time. For example iadd. Adding a Laneage argument would add unnecessary noise when using scalars only.

The panic version doesn't require capturing and resolving all frames in advance. This is faster and would be essential for displaying a backtrace in case of OOM or stackoverflow if we want to do thzt in the future because it requires much less memory.

A slight (<0.4%) slowdown for many benchmarks with a outliers of 0.6% (full) / 1.0% (incr-full) for the ctfe-stress-4 variants.

Replacing NxM with V128 would require a new variant of many instructions for every lane size. The current design allows using the same iadd instruction for every integer type both scalar and vector. It is also useful for typechecking CLIF derived from rust, as rust doesn't allow mixing vector types without an explicit transmute.

This doesn't offer any way to get the old behavior back. The old behavior os useful for shells where ctrl-c would result in EINTR. It should cancel the input in that case.

^ cc @pietroalbini

Interesting. It seems that the enum rule only matches enum Name and interprets the part between { and } as if it isn't an enum declaration. This means that tuple variants get interpreted as function calls.

Enum variants should always start with a capital first letter. (There is a lint for that) This means they should always get the type textmate scope.