- Jun 18, 2022
-
-
Han-Kuan Chen authored
This is a pre-commit test cases for D128039. Differential Revision: https://reviews.llvm.org/D128040
-
NAKAMURA Takumi authored
Fixup to llvmorg-15-init-12347-gf06abbb3 The difference of basename affects its emitted object file. FIXME: Each rule's name is left as origin.
-
Chris Bieneman authored
How does Windows not have bzero? How did I break this while working on a Windows-specific component of LLVM? The world may never know...
-
Chris Bieneman authored
This is the last piece to bring together writing DXContainer files containing DXIL through the DirectX backend. While this change only has one test, all of the tests under llvm/test/tools/dxil-dis also exercise this code. With this change the output object file type for the dxil target is now DXContainer. Each of the existing tests will generate DXContainer files, and the dxil-dis tests additionally verify that the DXContainers generated are well-formed and can be parsed by the DirectXShaderCompiler tools. Depends on D127153 and D127165 Differential Revision: https://reviews.llvm.org/D127166
-
LLVM GN Syncbot authored
-
Chris Bieneman authored
DXContainer files resemble traditional object files in that they are comprised of parts which resemble sections. Adding DXContainer as an object file format in the MC layer will allow emitting DXContainer objects through the normal object emission pipeline. Differential Revision: https://reviews.llvm.org/D127165
-
Chris Bieneman authored
The DXILAsmPrinter will just write globals into sections, so the DXILAsmPrinter only needs support for emitting global variables, and is otherwise a stub. Depends on D127147 Differential Revision: https://reviews.llvm.org/D127153
-
Chris Bieneman authored
This patch adds no-op stubs overrides for the MCRegisterInfo and MCFrameLowering for the DirectX/DXIL code generation path. Since DXIL will not generate MCInstrs these stubs do nothing, but they need to exist so that the MC layer can be used to emit DXContainer objects. Differential Revision: https://reviews.llvm.org/D127147
-
Felipe de Azevedo Piovezan authored
Type attributes are currently printed as: DW_AT_type (<address> "<name>") For example: DW_AT_type (0x00000086 "double") However, containing_type attributes omit the name, for example: DW_AT_containing_type (0x00000086) In order to make the dwarf dumps easier to read, and to have consistency between the type-like attributes, this commit changes the way DW_AT_containing_type is printed so that it includes the name of the type it refers to: DW_AT_containing_type (0x00000086 "double") Reviewed By: dblaikie Differential Revision: https://reviews.llvm.org/D127078
-
Vitaly Buka authored
-
David Blaikie authored
-
Akira Hatanaka authored
Instead, just pop the cleanups at the end of the asm statement. This fixes an assertion failure in BuildStmtExpr. It also fixes a bug where blocks and C compound literals were destructed at the end of the asm statement instead of at the end of the enclosing scope. Differential Revision: https://reviews.llvm.org/D125936
-
Michael Jones authored
The pointer converter handles the %p conversion. It uses the hex converter for most of the conversion. Reviewed By: sivachandra Differential Revision: https://reviews.llvm.org/D127995
-
Huan Nguyen authored
Resolve a crash related to split functions Due to split function optimization, a function can be divided to two fragments, and both fragments can access same jump table. This violates the assumption that a jump table can only have one parent function, which causes a crash during instrumentation. We want to support the case: different functions cannot access same jump tables, but different fragments of same function can! As all fragments are from same function, we point JT::Parent to one specific fragment. Right now it is the first disassembled fragment, but we can point it to the function's main fragment later. Functions are disassembled sequentially. Previously, at the end of processing a function, JT::OffsetEntries is cleared, so other fragment can no longer reuse JT::OffsetEntries. To extend the support for split function, we only clear JT::OffsetEntries after all functions are disassembled. Let say A.hot and A.cold access JT of three targets {X, Y, Z}, where X and Y are in A.hot, and Z is in A.cold. Suppose that A.hot is disassembled first, JT::OffsetEntries = {X',Y',INVALID_OFFSET}. When A.cold is disassembled, it cannot reuse JT::OffsetEntries above due to different fragment start. A simple solution: A.hot = {X',Y',INVALID_OFFSET} A.cold = {INVALID_OFFSET, INVALID_OFFSET, INVALID_OFFSET} We update the assertion to allow different fragments of same function to get the same JumpTable object. Potential improvements: A.hot = {X',Y',INVALID_OFFSET} A.cold = {INVALID_OFFSET, INVALID_OFFSET, Z'} The main issue is A.hot and A.cold have separate CFGs, thus jump table targets are still constrained within fragment bounds. Future improvements: A.hot = {X, Y, Z} A.cold = {X, Y, Z} Reviewed By: Amir Differential Revision: https://reviews.llvm.org/D127924 -
bixia1 authored
Support complex types of float and double. See the added test for an example. Reviewed By: aartbik Differential Revision: https://reviews.llvm.org/D128076
-
Arthur Eubanks authored
Use opaque pointers, remove obsolete FIXMEs, precommit test. Add extra `CHECK-NOT: norecurse`s because it can appear before the checked attributes.
-
Christopher Bate authored
Differential Revision: https://reviews.llvm.org/D128088
-
Jonas Devlieghere authored
Fix modernize-use-equals-default warnings. Because this check is listed in LLDB's top level .clang-tidy configuration, the check is enabled by default and the resulting warnings show up in my editor. I've audited the modified lines. This is not a blind change.
-
Jonas Devlieghere authored
Fix modernize-use-override warnings. Because this check is listed in LLDB's top level .clang-tidy configuration, the check is enabled by default and the resulting warnings show up in my editor. I've audited the modified lines. This is not a blind change.
-
Jan Svoboda authored
Previously, each job would overwrite the -MJ file. This didn't quite work for Clang invocations with multiple architectures, which got fixed in D121997 by always appending to the -MJ file. That's not correct either, since the file would grow indefinitely on subsequent Clang invocations. This patch ensures the driver always removes the file before jobs fill it in by appending. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D128098
-
Sunho Kim authored
Removes memory leak of ASTContext and TargetMachine. When DisableFree is turned on, it intentionally leaks these instances as they can be trivially deallocated. This patch turns this off and delete Parser instance early so that they will not reference dangling pargma headers. Asan shouldn't detect these as leaks normally, since burypointer is called for them. But, every invocation of incremental parser createa an additional leak of TargetMachine. If there are many invocations within a single test case, we easily reach number of leaks exceeding kGraveYardMaxSize (which is 12) and leaks start to get reported by asan buildbots. Reviewed By: v.g.vassilev Differential Revision: https://reviews.llvm.org/D127991
-
Louis Dionne authored
Differential Revision: https://reviews.llvm.org/D127526
-
Dave Lee authored
Eliminate boilerplate of having each test manually assign to `mydir` by calling `compute_mydir` in lldbtest.py. Differential Revision: https://reviews.llvm.org/D128077
-
Louis Dionne authored
The optimization level used when building the benchmarks should match the optimization level of the current build. Otherwise, we can end up mixing an -O3 or -O0 optimized dylib with benchmarks built with -O2, which is really misleading. Differential Revision: https://reviews.llvm.org/D127987
-
Craig Topper authored
-
Benjamin Kramer authored
This library is supposed not to have a dependency on LLVM, and linking LLVMSupport into it breaks its shared library setup.
-
Rafael Auler authored
Temporary fix for missing entry offset when creating address translation tables (BAT) after D127935 landed. Will later work on assigning a more reasonable offset different than zero. Reviewed By: Amir Differential Revision: https://reviews.llvm.org/D128092
-
Benjamin Kramer authored
This is supposed to be header-only. Don't know how to express that in bazel.
-
Benjamin Kramer authored
This adds weak versions of the truncation libcalls in case the runtime environment doesn't have them. Differential Revision: https://reviews.llvm.org/D128091
-
Aart Bik authored
Sparse library ABI issues are fixed. https://github.com/llvm/llvm-project/issues/55992 Reviewed By: bkramer Differential Revision: https://reviews.llvm.org/D128086
-
Philip Reames authored
Should be fully covered by the generic demanded field based logic just below, and this ensures better coverage of that logic.
-
Philip Reames authored
Doing so let's the post-mutation pass leverage the demanded info to rewrite vsetvlis before a store/mask-op to eliminate later vsetvlis. Sorry for the lack of store test change; all of my attempts to write something reasonable have been handled through existing logic.
-
Florian Hahn authored
This reverts commit 7aa8a678. This version includes fixes to address issues uncovered after the commit landed and discussed at D11448. Those include: * Limit select-traversal to selects inside the loop. * Freeze pointers resulting from looking through selects to avoid branch-on-poison.
-
Sanjay Patel authored
-
Nikolas Klauser authored
Reviewed By: ldionne, Mordante, #libc, saugustine Spies: saugustine, MaskRay, arichardson, mstorsjo, jloser, libcxx-commits, arphaman Differential Revision: https://reviews.llvm.org/D127953
-
Chris Bieneman authored
The added section and table here list the object file formats LLVM MC supports and which targets support each format. Differential Revision: https://reviews.llvm.org/D127645
-
Chris Bieneman authored
This reverts commit 0dd243fa. I accidentally pushed this! Oops!
-
Frederik Gossen authored
Differential Revision: https://reviews.llvm.org/D128078
-
Chris Bieneman authored
This document is a work in progress to begin fleshing out documentation for the DirectX backend and related changes in the LLVM project. This is not intended to be exhaustive or complete, it is intended as a starting point so taht future changes have a place for documentation to land. Differential Revision: https://reviews.llvm.org/D127640
-
Chris Bieneman authored
-