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

dl: Adapt to opaque pointers #113

Open
langston-barrett opened this issue Oct 28, 2022 · 0 comments
Open

dl: Adapt to opaque pointers #113

langston-barrett opened this issue Oct 28, 2022 · 0 comments

Comments

@langston-barrett
Copy link
Collaborator

LLVM is in the process of migrating all of its pointer types from i8*, i32*, etc. to an opaque ptr type, as described here. LLVM 13 takes an important step in that direction, as it is the first LLVM release to include ptr in the LLVM AST. See llvm/llvm-project@2155dc5. LLVM 15 switches to opaque pointers by default, so this impacts #12.

It's not clear to me what impact this will have on cclyzer++. cclyzer++ creates suballocations based on allocation type, but it seems like alloca still takes the type parameter that cclyzer++ uses to assign types to allocations. Type back-propagation may need minor adjustments to get the type from the load and store instructions themselves, rather than the type of their operand (which will now always be ptr).

Opaque pointers can be disabled through LLVM 15 with -opaque-pointers=1 in opt and -Xclang -no-opaque-pointers for clang.

If there is a big impact, there are at least three ways we could handle this, from trivial to research-grade difficulty:

  • Default to making allocations have type i8
  • Use type back-propagation from loads and stores more aggressively
  • Adopt a memory model that doesn't care so much about types (dl: Offset-based memory model #112)
@langston-barrett langston-barrett changed the title Adapt to opaque pointers dl: Adapt to opaque pointers Oct 28, 2022
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

1 participant