Skip to content

noalias on all parameters by default (with debug safety); ability to specify mayalias #1108

Open
@andrewrk

Description

@andrewrk
Member

I'm extracting this (flawed) proposal out of #733.

  • Add mayalias keyword
  • Remove noalias keyword
  • mayalias valid only on a pointer parameter. It means "may be aliased by global variables or other arguments to this function which are mutable pointers"
  • Debug safety
    • At the beginning of each function, verify that no mutable pointers with known sizes (*T, *[N]T, and []T) overlap with each other, or with any const pointers with known sizes
  • In Zig IR, pointer values track the set of noalias parameters and global variables possibly referenced
    • slice and getelementptr instructions that include a noalias var of
      unknown len ptr in the set do a safety check to find overlap
  • When generating LLVM,
    • load instructions based on const ptr noalias variables !alias.scope
      a scope unique to the function but shared by each other (the function's
      const ptr alias scope)
    • load instructions based on mut ptr noalias variables !alias.scope
      a unique scope per var
    • Store instructions based on noalias variables !noalias all the
      function's noalias var scopes they are not based on, and the function's
      const ptr alias scope
  • Verify that LLVM can take advantage of these annotations

Depends on #561 so we can put llvm parameter attributes on slice pointers

This proposal needs work. Consider this example:

const Context = struct {
    // some useful fields, and then
    preallocated_point: Point,
};

const Point = struct {
    x: i32,
    y: i32,
}

fn incrementXAndPrint(self: *Context, pt: *Point) {
    pt.x += 1;
    self.log("point: {v}\n", pt);
}

test "aoeu" {
    var c = Context {
        .preallocated_point = Point { .x = 0, .y = 0 },
    };
    incrementXAndPrint(&c, &c.preallocated_point);
}

This would trigger the proposed debug safety but it does not actually represent problematic behavior, since the value is never accessed via the other pointer.

One proposal adjustment could be to do all the runtime safety only at store instructions for everything. I fear this would be too slow in practice, however it is worth experimenting with before shutting the idea down. I'll first verify that LLVM would be able to take advantage of these annotations though.

Activity

added
breakingImplementing this issue could cause existing code to no longer compile or have different behavior.
proposalThis issue suggests modifications. If it also has the "accepted" label then it is planned.
on Jun 13, 2018
added this to the 0.4.0 milestone on Jun 13, 2018
andrewrk

andrewrk commented on Sep 26, 2018

@andrewrk
MemberAuthor

Related: #476

modified the milestones: 0.4.0, 0.5.0 on Nov 21, 2018
daurnimator

daurnimator commented on Nov 28, 2018

@daurnimator
Contributor

I'll first verify that LLVM would be able to take advantage of these annotations though.

It is, but there have been some issues. It looks like rust currently has related optimizations disabled due to rust-lang/rust#54878

daurnimator

daurnimator commented on Jul 20, 2019

@daurnimator
Contributor
  • mayalias valid only on a pointer parameter. It means "may be aliased by global variables or other arguments to this function which are mutable pointers"

What if you could provide a list of variables that it might alias?

removed this from the 0.5.0 milestone on Aug 16, 2019

16 remaining items

modified the milestones: 0.9.0, 0.10.0 on Nov 23, 2021
modified the milestones: 0.10.0, 0.11.0 on Apr 16, 2022
modified the milestones: 0.11.0, 0.12.0 on Apr 9, 2023
modified the milestones: 0.13.0, 0.12.0 on Jul 9, 2023
moved this to To do in Safetyon Aug 22, 2024
modified the milestones: 0.14.0, 0.15.0 on Feb 10, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    breakingImplementing this issue could cause existing code to no longer compile or have different behavior.proposalThis issue suggests modifications. If it also has the "accepted" label then it is planned.researchThis proposal requires a considerable amount of investigation before it can be considered.

    Type

    No type

    Projects

    Status

    To do

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @andrewrk@daurnimator@SpexGuy@JesseRMeyer@matu3ba

        Issue actions

          noalias on all parameters by default (with debug safety); ability to specify mayalias · Issue #1108 · ziglang/zig