Skip to content

add safety for noalias on a parameter #476

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

Open
andrewrk opened this issue Sep 14, 2017 · 3 comments
Open

add safety for noalias on a parameter #476

andrewrk opened this issue Sep 14, 2017 · 3 comments
Labels
proposal This issue suggests modifications. If it also has the "accepted" label then it is planned. research This proposal requires a considerable amount of investigation before it can be considered.
Milestone

Comments

@andrewrk
Copy link
Member

When you call a function with pointer arguments marked as noalias, such as @memcpy, it is undefined behavior for the pointer arguments to point to the same memory. We can insert a safety check for this. It should be pretty low cost.

This should work for slices too, and it should ensure that the slices do not overlap. In order for the optimizer to potentially be able to use this information, we should probably pass slices as 2 parameters, the pointer and the length. This way we can add parameter attributes to the pointer parameter.

@andrewrk andrewrk added the enhancement Solving this issue will likely involve adding new logic or components to the codebase. label Sep 14, 2017
@andrewrk andrewrk added this to the 0.2.0 milestone Sep 14, 2017
@andrewrk andrewrk modified the milestones: 0.2.0, 0.3.0 Oct 19, 2017
@andrewrk andrewrk modified the milestones: 0.3.0, 0.4.0 Feb 28, 2018
@BarabasGitHub
Copy link
Contributor

we should probably pass slices as 2 parameters, the pointer and the length. This way we can add parameter attributes to the pointer parameter.

Can't you do a noalias on a slice? Or are slices internally passed by reference currently?

@andrewrk andrewrk modified the milestones: 0.4.0, 0.5.0 Feb 15, 2019
@andrewrk andrewrk modified the milestones: 0.5.0, 0.6.0 Sep 11, 2019
@andrewrk andrewrk modified the milestones: 0.6.0, 0.7.0 Feb 10, 2020
@andrewrk andrewrk added proposal This issue suggests modifications. If it also has the "accepted" label then it is planned. and removed enhancement Solving this issue will likely involve adding new logic or components to the codebase. labels Oct 9, 2020
@andrewrk andrewrk modified the milestones: 0.7.0, 0.8.0 Oct 9, 2020
@matu3ba
Copy link
Contributor

matu3ba commented Jan 26, 2021

This should work for slices too, and it should ensure that the slices do not overlap. In order for the optimizer to potentially be able to use this information, we should probably pass slices as 2 parameters, the pointer and the length. This way we can add parameter attributes to the pointer parameter.

Fingers crossed that the LLVM IR does not break everything, once they enable noalias. This would also require implementing pointer provenance.

@andrewrk andrewrk added the research This proposal requires a considerable amount of investigation before it can be considered. label Apr 21, 2021
@andrewrk andrewrk modified the milestones: 0.8.0, 0.9.0 Apr 21, 2021
@andrewrk andrewrk modified the milestones: 0.9.0, 0.10.0 May 19, 2021
@tau-dev
Copy link
Contributor

tau-dev commented Jul 12, 2024

Just comparing a function's arguments would be useful already, but complete safety coverage would require run-time tracking of pointer provenance, through e.g. fat pointers. This could subsume our use of the AddressSanitizer; as far as I recall, addrsan's shadow heap is significantly faster than pointer tagging, but there has been some recent research on this topic, which may at least offer lower memory overhead than addrsan as a tradeoff.

A potentially a much larger downside is that no tagging approach (that I'm aware of) can preserve full compatibility with non-instrumented code. This is rather fundamental, as LLVM's semantics associate properties with the individual pointer values, not just the addresses they refer to, but I don't think it's completely unsolvable; maybe we can come up with a custom sanitizer of our own?

@mlugg mlugg added this to Safety Aug 22, 2024
@mlugg mlugg moved this to To do in Safety Aug 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
proposal This issue suggests modifications. If it also has the "accepted" label then it is planned. research This proposal requires a considerable amount of investigation before it can be considered.
Projects
Status: To do
Development

No branches or pull requests

4 participants