| commit | fc538b070de69315fe05105e8c0bc622fb61168a | [log] [tgz] |
|---|---|---|
| author | Craig Topper <craig.topper@sifive.com> | Wed Apr 24 12:31:14 2024 -0700 |
| committer | GitHub <noreply@github.com> | Wed Apr 24 12:31:14 2024 -0700 |
| tree | 7a9d7d19fa1b12ebc78de5305ba33266c65530f6 | |
| parent | 03bb10dfb3725ec2c31fb66deede96d066f2b49a [diff] |
[SelectionDAG] Pass SDVTList instead of VTs to *SDNode constructors. NFC (#89880) All of these constructors were creating a SDVTList using an EVT* created by SDNode::getValueTypeList. This EVT needs to live at least as long as the SDNode that uses it. To do this, SDNode::getValueTypeList contains several function scoped static variables that hold the memory for the EVT. So the EVT lives until global destructors run. This is problematic since an EVT contains a Type* that points to memory allocated by an LLVMContext. If multiple LLVMContexts are used that don't have overlapping lifetimes, we can end up with stale or or incorrect pointers cached in the EVTs owned by SDNode::getValueTypeList. I want to try to make the EVTs be owned by SelectionDAG instead. This is already done for SDVTLists with more than 1 VT. The single value case is a very old optimizaton that should be re-evaluated. In order to do this, I need the SDVTLists to be created by SelectionDAG rather than by the SDNode itself. This patch doesn't change how the allocation is done yet. It just moves the code around. This patch does reduce the number of calls to getVTList since we now share with the call needed for the SDNode FoldingSet. Part of fixing #88233.
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.
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.
Join the LLVM Discourse forums, Discord chat, LLVM Office Hours or Regular sync-ups.
The LLVM project has adopted a code of conduct for participants to all modes of communication within the project.