53e9a5ddc0
This models the approach used in LFTR. The short summary is that we need to prove the IV is not dead first, and then we have to either prove the poison flag is valid after the new user or delete it. There are two key differences between this and LFTR. First, I allow a non-concrete start to the IV. The goal of LFTR is to canonicalize and IVs with constant starts are canonical, so the very restrictive definition there is mostly okay. Here on the other hand, we're explicitly moving *away* from the canonical form, and thus need to handle non-constant starts. Second, LFTR bails out instead of removing inbounds on a GEP. This is a pragmatic tradeoff since inbounds is hard to infer and assists aliasing. This pass runs very late, and I think the tradeoff runs the other way. A different approach we could take for the post-inc check would be to perform a pre-inc check instead of a post-inc check. We would still have to check the pre-inc IV, but that would avoid the need to drop inbounds. Doing the pre-inc check would basically trade killing a whole IV for an extra register move in the loop. I'm open to suggestions on the right approach here. Note that this analysis is quite expensive compile time wise. I have made no effort to optimize (yet). Differential Revision: https://reviews.llvm.org/D146464 |
||
|---|---|---|
| .github | ||
| bolt | ||
| clang | ||
| clang-tools-extra | ||
| cmake | ||
| compiler-rt | ||
| cross-project-tests | ||
| flang | ||
| libc | ||
| libclc | ||
| libcxx | ||
| libcxxabi | ||
| libunwind | ||
| lld | ||
| lldb | ||
| llvm | ||
| llvm-libgcc | ||
| mlir | ||
| openmp | ||
| polly | ||
| pstl | ||
| runtimes | ||
| third-party | ||
| utils | ||
| .arcconfig | ||
| .arclint | ||
| .clang-format | ||
| .clang-tidy | ||
| .git-blame-ignore-revs | ||
| .gitignore | ||
| .mailmap | ||
| CONTRIBUTING.md | ||
| LICENSE.TXT | ||
| README.md | ||
| SECURITY.md | ||
The LLVM Compiler Infrastructure
Welcome to the LLVM project!
This repository contains the source code for LLVM, a toolkit for the construction of highly optimized compilers, optimizers, and run-time environments.
The LLVM project has multiple components. The core of the project is itself called "LLVM". This contains all of the tools, libraries, and header files needed to process intermediate representations and convert them into object files. Tools include an assembler, disassembler, bitcode analyzer, and bitcode optimizer.
C-like languages use the Clang frontend. This component compiles C, C++, Objective-C, and Objective-C++ code into LLVM bitcode -- and from there into object files, using LLVM.
Other components include: the libc++ C++ standard library, the LLD linker, and more.
Getting the Source Code and Building LLVM
Consult the Getting Started with LLVM page for information on building and running LLVM.
For information on how to contribute to the LLVM project, please take a look at the Contributing to LLVM guide.
Getting in touch
Join the LLVM Discourse forums, Discord chat, or #llvm IRC channel on OFTC.
The LLVM project has adopted a code of conduct for participants to all modes of communication within the project.