Add intrinsics for operating on raw_ptrs

[AlicanC]

This PR:

• Adds __ptr_add<T>(ptr: raw_ptr, count: u64) (which basically does ptr + __size_of::<T>() * count) and its sub counterpart to be used in pointer offset calculations.
• Makes std::alloc::* and raw_ptr::* have type arguments and work in increments of size_of::<T>() instead of bytes.
• Removes test fixing_generic_type which was broken instead of maintaining it. This test was created to reproduce an issue I was having a few months ago. Fixing this allowed other things to be built so there are other tests that touch this case.

---

This abstracts away more hacky stuff from the Sway side, and also significantly reduces bytecode size in some tests, especially in Vec stuff:

Test	Before	After	Change
should_pass/stdlib/alloc	684	948	27.85%
should_fail/vec_swap_param2_out_of_bounds	1028	1132	9.19%
should_fail/vec_swap_param1_out_of_bounds	1028	1132	9.19%
should_pass/stdlib/raw_ptr	1964	2020	2.77%
should_pass/stdlib/vec_swap	32764	33460	2.08%
should_pass/stdlib/vec	175952	178992	1.70%

Related: #3112

[mohammadfawaz]

That's amazing 🚀 . Do you mind checking the impact of this on the sway-applications repo?

[AlicanC]

Do you mind checking the impact of this on the sway-applications repo?

I was surprised at first to see not even a single app's size change, but then realized we use Vec in only one app and that's just two method calls or something.

So 0% change on sway-applications.

[mohammadfawaz]

Ok so one more comment. Otherwise, is this ready for review? You also seem to have a merge conflict now :/

[AlicanC]

Otherwise, is this ready for review?

Well IDK really.

This only improves Vec and if we are to improve Vec it would be better to have separate intrinsics like __ptr_add(ptr: raw_ptr, len: u64, count: u64) where we do raw_ptr += len * count which is what Vec really needs.

If we had typed pointers, then the signature would be __ptr_add<T>(ptr: ptr<T>, count: u64) where we get len from __size_of::<T>.

[mohammadfawaz]

Otherwise, is this ready for review?

Well IDK really.

This only improves Vec and if we are to improve Vec it would be better to have separate intrinsics like __ptr_add(ptr: raw_ptr, len: u64, count: u64) where we do raw_ptr += len * count which is what Vec really needs.

If we had typed pointers, then the signature would be __ptr_add<T>(ptr: ptr<T>, count: u64) where we get len from __size_of::<T>.

You may be right in the sense that it's odd to reuse the binary intrinsics __add and __sub and hacking them to allow accepting two values of different types (raw_ptr and u64). Besides, we also have to disallow __mul and __div for raw_ptr. @otrho what do you think?

[otrho]

Yeah, you're (both) right. __ptr_add() sounds like a way better solution. Doing arithmetic on pointers should obviously be discouraged and constrained.

[AlicanC]

Ok, so this version adds __ptr_add<T>(ptr: raw_ptr, count: u64) and its sub.

I've also made std::alloc::* and raw_ptr::* have type arguments and work in increments of size_of::<T>() instead of bytes. This introduces a constraint since T has to be multiples of 8 in Sway. (You can't alloc 1 byte, 7 bytes, etc. anymore, only multiples of 8.) I think this is a nice constraint to have since Sway is word-sized and not byte-sized.

I've also removed a test that was broken. It was a test I was familiar with, and what's being tested there should have no way of not being caught by other tests since we started making heavy usage of it after it was fixed.

[mohammadfawaz]

This seems more reasonable and safer. Thanks!

• Just one small question in one of the tests
• Also, why are we deleting the test fixing_generic_type?
• Finally, will you please update the PR description to reflect the new approach?

[AlicanC]

@mohammadfawaz updated the PR desc!