llvm / llvm/llvm-project

Operational semantics for allocator elision

Open
#184,102 1 comment 0 reactions 0 assignees View on GitHub
llvm:ir
Dominant language
LLVM
Stars
40.5k
Forks
18.7k
PR merge metrics
PR metrics pending

Description

https://github.com/llvm/llvm-project/pull/177592 specifies allocation elision in terms of allowed transformation.

The resulting semantics are angelic in nature, as they require knowing whether a free with the same alloc-family occurs in the future. Ideally, we would find a way to make these semantics operational.

The thing that makes this non-trivial is that the free call may be inlined, in which case allocation elision can no longer be applied.

Contributor guide

Open the contributing guide

Research direction

Start by reading PR 177592, which specifies allocation elision as an allowed transformation. Examine how its semantics depend on a future free with the same alloc-family and how inlining affects whether elision can be applied. Done means defining an operational alternative that addresses the inlined-free case.

Written by the indexing model from the issue text.

Assessment

Domain
compilers
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.