Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

malloc, calloc, ... should use the #[allocator] attribute #108

Open
gnzlbg opened this issue Feb 11, 2019 · 4 comments
Open

malloc, calloc, ... should use the #[allocator] attribute #108

gnzlbg opened this issue Feb 11, 2019 · 4 comments

Comments

@gnzlbg
Copy link
Owner

gnzlbg commented Feb 11, 2019

@alexcrichton malloc, calloc, etc. do not return a noalias pointer, I think they should use the #[allocator] attribute but that's currently super unstable. Any ideas ?

@gnzlbg gnzlbg changed the title malloc, cmalloc, etc. should use the #[allocator] attribute malloc, calloc, ... should use the #[allocator] attribute Feb 11, 2019
@alexcrichton
Copy link
Collaborator

Ideally, yes, but this is unlikely to really benefit much in practice. Usage via #[global_allocator] aleady has these attributes elsewhere, so there's no burning need for this crate to use them.

@gnzlbg
Copy link
Owner Author

gnzlbg commented Feb 11, 2019

AFAIK those attributes are only added to GlobalAlloc::alloc, but if someone uses the Alloc trait, e.g., for Alloc::alloc_zeroed, then these attributes are not added.

Also, libc exposes many allocation functions, like malloc, that should have these attributes, but currently don't, so we should also add #[allocator] to those.

@alexcrichton
Copy link
Collaborator

That's correct, yeah. In general we're not too interested in adding all possible LLVM attributes to all possible functions, it's mainly just a stabilization headache/maintenance nightmare for very little benefit

@gnzlbg
Copy link
Owner Author

gnzlbg commented Feb 11, 2019

IIRC libstd already uses calloc when possible, and without #[allocator] LLVM can't know that this function allocates memory. For that, the pointer returned has to be noalias, otherwise it can alias with other pointers.

Fixing this would need some kind of stabilized #[unsafe_allocator] attribute, that users can apply to either their allocators or their Alloc trait impls.

it's mainly just a stabilization headache/maintenance nightmare

There is prior art for these attributes in both GCC and LLVM, and we are arguably already using them, so they must be solving some problem already. I can write an MVP RFC for this.

Basically, we would introduce an #[unsafe_allocator] attribute that would optionally take some parameters with the following semantics in LLVM (in Cretonne or GCC these would be different):

  • #[allocator]: adds the noalias attribute to the return value of the function
  • #[allocator(size = n): adds the allocsize(N) attribute to the function
  • #[allocator(size = n, number = m)]: adds the allocsize(n, m) attribute to the function
  • #[allocator(align = n)]: adds an LLVM CreateAlignmentAssumption to the function

This would allow to specify most properties of the malloc API:

#[allocator(size = s, align = a)]
fn my_malloc(s: usize, a: usize) -> *mut u8;

#[allocator(size = s, number = n, align = a)]
fn my_calloc(s: usize, n: usize, a: align) -> *mut u8;

#[allocator(align = a, size = s)]
fn my_aligned_alloc(a: usize, s: usize) -> *mut u8; 

#[allocator(size = s)]
fn my_realloc(ptr: *mut u8, s: usize) -> *mut u8;  

I'm not 100% sure, but IIRC realloc-like functions "launder" the pointer (cc @rkruppe), so it would be ok for the result to be noalias. User code could then use core::intrinsic::assume to state that the alignment of the result is >= the alignment of the ptr argument, or maybe we could also support align = n on ptr arguments somehow.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants