RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-11-22 18:54:02 +01:00
Code Issues Projects Releases Wiki Activity
033e597afe
llvm-mirror/unittests/CodeGen/MachineInstrTest.cpp

393 lines
14 KiB
C++
Raw Normal View History

MachineInstr: Make isEqual agree with getHashValue in MachineInstrExpressionTrait MachineInstr::isIdenticalTo has a lot of logic for dealing with register Defs (i.e. deciding whether to take them into account or ignore them). This logic gets things wrong in some obscure cases, for instance if an operand is not a Def for both the current MI and the one we are comparing to. I'm not sure if it's possible for this to happen for regular register operands, but it may happen in the ARM backend for special operands which use sentinel values for the register (i.e. 0, which is neither a physical register nor a virtual one). This causes MachineInstrExpressionTrait::isEqual (which uses MachineInstr::isIdenticalTo) to return true for the following instructions, which are the same except for the fact that one sets the flags and the other one doesn't: %1114 = ADDrsi %1113, %216, 17, 14, _, def _ %1115 = ADDrsi %1113, %216, 17, 14, _, _ OTOH, MachineInstrExpressionTrait::getHashValue returns different values for the 2 instructions due to the different isDef on the last operand. In practice this means that when trying to add those instructions to a DenseMap, they will be considered different because of their different hash values, but when growing the map we might get an assertion while copying from the old buckets to the new buckets because isEqual misleadingly returns true. This patch makes sure that isEqual and getHashValue agree, by improving the checks in MachineInstr::isIdenticalTo when we are ignoring virtual register definitions (which is what the Trait uses). Firstly, instead of checking isPhysicalRegister, we use !isVirtualRegister, so that we cover both physical registers and sentinel values. Secondly, instead of checking MachineOperand::isReg, we use MachineOperand::isIdenticalTo, which checks isReg, isSubReg and isDef, which are the same values that the hash function uses to compute the hash. Note that the function is symmetric with this change, since if the current operand is not a Def, we check MachineOperand::isIdenticalTo, which returns false if the operands have different isDef's. Differential Revision: https://reviews.llvm.org/D38789 llvm-svn: 315579
2017-10-12 15:59:51 +02:00
//===- MachineInstrTest.cpp -----------------------------------------------===//
//
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
2019-01-19 09:50:56 +01:00
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
MachineInstr: Make isEqual agree with getHashValue in MachineInstrExpressionTrait MachineInstr::isIdenticalTo has a lot of logic for dealing with register Defs (i.e. deciding whether to take them into account or ignore them). This logic gets things wrong in some obscure cases, for instance if an operand is not a Def for both the current MI and the one we are comparing to. I'm not sure if it's possible for this to happen for regular register operands, but it may happen in the ARM backend for special operands which use sentinel values for the register (i.e. 0, which is neither a physical register nor a virtual one). This causes MachineInstrExpressionTrait::isEqual (which uses MachineInstr::isIdenticalTo) to return true for the following instructions, which are the same except for the fact that one sets the flags and the other one doesn't: %1114 = ADDrsi %1113, %216, 17, 14, _, def _ %1115 = ADDrsi %1113, %216, 17, 14, _, _ OTOH, MachineInstrExpressionTrait::getHashValue returns different values for the 2 instructions due to the different isDef on the last operand. In practice this means that when trying to add those instructions to a DenseMap, they will be considered different because of their different hash values, but when growing the map we might get an assertion while copying from the old buckets to the new buckets because isEqual misleadingly returns true. This patch makes sure that isEqual and getHashValue agree, by improving the checks in MachineInstr::isIdenticalTo when we are ignoring virtual register definitions (which is what the Trait uses). Firstly, instead of checking isPhysicalRegister, we use !isVirtualRegister, so that we cover both physical registers and sentinel values. Secondly, instead of checking MachineOperand::isReg, we use MachineOperand::isIdenticalTo, which checks isReg, isSubReg and isDef, which are the same values that the hash function uses to compute the hash. Note that the function is symmetric with this change, since if the current operand is not a Def, we check MachineOperand::isIdenticalTo, which returns false if the operands have different isDef's. Differential Revision: https://reviews.llvm.org/D38789 llvm-svn: 315579
2017-10-12 15:59:51 +02:00
//
//===----------------------------------------------------------------------===//
#include "llvm/CodeGen/MachineInstr.h"
[MC] Untangle MCContext and MCObjectFileInfo This untangles the MCContext and the MCObjectFileInfo. There is a circular dependency between MCContext and MCObjectFileInfo. Currently this dependency also exists during construction: You can't contruct a MOFI without a MCContext without constructing the MCContext with a dummy version of that MOFI first. This removes this dependency during construction. In a perfect world, MCObjectFileInfo wouldn't depend on MCContext at all, but only be stored in the MCContext, like other MC information. This is future work. This also shifts/adds more information to the MCContext making it more available to the different targets. Namely: - TargetTriple - ObjectFileType - SubtargetInfo Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D101462
2021-05-05 19:03:02 +02:00
#include "llvm/ADT/Triple.h"
#include "llvm/CodeGen/MachineBasicBlock.h"
MachineInstr: Make isEqual agree with getHashValue in MachineInstrExpressionTrait MachineInstr::isIdenticalTo has a lot of logic for dealing with register Defs (i.e. deciding whether to take them into account or ignore them). This logic gets things wrong in some obscure cases, for instance if an operand is not a Def for both the current MI and the one we are comparing to. I'm not sure if it's possible for this to happen for regular register operands, but it may happen in the ARM backend for special operands which use sentinel values for the register (i.e. 0, which is neither a physical register nor a virtual one). This causes MachineInstrExpressionTrait::isEqual (which uses MachineInstr::isIdenticalTo) to return true for the following instructions, which are the same except for the fact that one sets the flags and the other one doesn't: %1114 = ADDrsi %1113, %216, 17, 14, _, def _ %1115 = ADDrsi %1113, %216, 17, 14, _, _ OTOH, MachineInstrExpressionTrait::getHashValue returns different values for the 2 instructions due to the different isDef on the last operand. In practice this means that when trying to add those instructions to a DenseMap, they will be considered different because of their different hash values, but when growing the map we might get an assertion while copying from the old buckets to the new buckets because isEqual misleadingly returns true. This patch makes sure that isEqual and getHashValue agree, by improving the checks in MachineInstr::isIdenticalTo when we are ignoring virtual register definitions (which is what the Trait uses). Firstly, instead of checking isPhysicalRegister, we use !isVirtualRegister, so that we cover both physical registers and sentinel values. Secondly, instead of checking MachineOperand::isReg, we use MachineOperand::isIdenticalTo, which checks isReg, isSubReg and isDef, which are the same values that the hash function uses to compute the hash. Note that the function is symmetric with this change, since if the current operand is not a Def, we check MachineOperand::isIdenticalTo, which returns false if the operands have different isDef's. Differential Revision: https://reviews.llvm.org/D38789 llvm-svn: 315579
2017-10-12 15:59:51 +02:00
#include "llvm/CodeGen/MachineFunction.h"
Recommit "Add a heap alloc site marker field to the ExtraInfo in MachineInstrs" Summary: Fixes some things from original commit at https://reviews.llvm.org/D69136. The main change is that the heap alloc marker is always stored as ExtraInfo in the machine instruction instead of in the PointerSumType because it cannot hold more than 4 pointer types. Add instruction marker to MachineInstr ExtraInfo. This does almost the same thing as Pre/PostInstrSymbols, except that it doesn't create a label until printing instructions. This allows for labels to be put around instructions that are deleted/duplicated somewhere. Use this marker to track heap alloc site call instructions. Reviewers: rnk Subscribers: MatzeB, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69536
2019-10-28 22:53:32 +01:00
#include "llvm/CodeGen/MachineMemOperand.h"
MachineInstr: Make isEqual agree with getHashValue in MachineInstrExpressionTrait MachineInstr::isIdenticalTo has a lot of logic for dealing with register Defs (i.e. deciding whether to take them into account or ignore them). This logic gets things wrong in some obscure cases, for instance if an operand is not a Def for both the current MI and the one we are comparing to. I'm not sure if it's possible for this to happen for regular register operands, but it may happen in the ARM backend for special operands which use sentinel values for the register (i.e. 0, which is neither a physical register nor a virtual one). This causes MachineInstrExpressionTrait::isEqual (which uses MachineInstr::isIdenticalTo) to return true for the following instructions, which are the same except for the fact that one sets the flags and the other one doesn't: %1114 = ADDrsi %1113, %216, 17, 14, _, def _ %1115 = ADDrsi %1113, %216, 17, 14, _, _ OTOH, MachineInstrExpressionTrait::getHashValue returns different values for the 2 instructions due to the different isDef on the last operand. In practice this means that when trying to add those instructions to a DenseMap, they will be considered different because of their different hash values, but when growing the map we might get an assertion while copying from the old buckets to the new buckets because isEqual misleadingly returns true. This patch makes sure that isEqual and getHashValue agree, by improving the checks in MachineInstr::isIdenticalTo when we are ignoring virtual register definitions (which is what the Trait uses). Firstly, instead of checking isPhysicalRegister, we use !isVirtualRegister, so that we cover both physical registers and sentinel values. Secondly, instead of checking MachineOperand::isReg, we use MachineOperand::isIdenticalTo, which checks isReg, isSubReg and isDef, which are the same values that the hash function uses to compute the hash. Note that the function is symmetric with this change, since if the current operand is not a Def, we check MachineOperand::isIdenticalTo, which returns false if the operands have different isDef's. Differential Revision: https://reviews.llvm.org/D38789 llvm-svn: 315579
2017-10-12 15:59:51 +02:00
#include "llvm/CodeGen/MachineModuleInfo.h"
Target/TargetInstrInfo.h -> CodeGen/TargetInstrInfo.h to match layering This header includes CodeGen headers, and is not, itself, included by any Target headers, so move it into CodeGen to match the layering of its implementation. llvm-svn: 317647
2017-11-08 02:01:31 +01:00
#include "llvm/CodeGen/TargetFrameLowering.h"
#include "llvm/CodeGen/TargetInstrInfo.h"
Fix a bunch more layering of CodeGen headers that are in Target All these headers already depend on CodeGen headers so moving them into CodeGen fixes the layering (since CodeGen depends on Target, not the other way around). llvm-svn: 318490
2017-11-17 02:07:10 +01:00
#include "llvm/CodeGen/TargetLowering.h"
#include "llvm/CodeGen/TargetSubtargetInfo.h"
[CodeGen] Unify printing format of debug-location in both MIR and -debug Use "debug-location" instead of "; dbg:" in MI::print. llvm-svn: 322936
2018-01-19 12:44:42 +01:00
#include "llvm/IR/DebugInfoMetadata.h"
[DebugInfo] Re-implement LexicalScopes dominance method, add unit tests Way back in D24994, the combination of LexicalScopes::dominates and LiveDebugValues was identified as having worst-case quadratic complexity, but it wasn't triggered by any code path at the time. I've since run into a scenario where this occurs, in a very large basic block where large numbers of inlined DBG_VALUEs are present. The quadratic-ness comes from LiveDebugValues::join calling "dominates" on every variable location, and LexicalScopes::dominates potentially touching every instruction in a block to test for the presence of a scope. We have, however, already computed the presence of scopes in blocks, in the "InstrRanges" of each scope. This patch switches the dominates method to examine whether a block is present in a scope's InsnRanges, avoiding walking through the whole block. At the same time, fix getMachineBasicBlocks to account for the fact that InsnRanges can cover multiple blocks, and add some unit tests, as Lexical Scopes didn't have any. Differential revision: https://reviews.llvm.org/D73725
2020-02-28 11:41:23 +01:00
#include "llvm/IR/IRBuilder.h"
[CodeGen] Unify printing format of debug-location in both MIR and -debug Use "debug-location" instead of "; dbg:" in MI::print. llvm-svn: 322936
2018-01-19 12:44:42 +01:00
#include "llvm/IR/ModuleSlotTracker.h"
Recommit "Add a heap alloc site marker field to the ExtraInfo in MachineInstrs" Summary: Fixes some things from original commit at https://reviews.llvm.org/D69136. The main change is that the heap alloc marker is always stored as ExtraInfo in the machine instruction instead of in the PointerSumType because it cannot hold more than 4 pointer types. Add instruction marker to MachineInstr ExtraInfo. This does almost the same thing as Pre/PostInstrSymbols, except that it doesn't create a label until printing instructions. This allows for labels to be put around instructions that are deleted/duplicated somewhere. Use this marker to track heap alloc site call instructions. Reviewers: rnk Subscribers: MatzeB, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69536
2019-10-28 22:53:32 +01:00
#include "llvm/MC/MCAsmInfo.h"
#include "llvm/MC/MCSymbol.h"
MachineInstr: Make isEqual agree with getHashValue in MachineInstrExpressionTrait MachineInstr::isIdenticalTo has a lot of logic for dealing with register Defs (i.e. deciding whether to take them into account or ignore them). This logic gets things wrong in some obscure cases, for instance if an operand is not a Def for both the current MI and the one we are comparing to. I'm not sure if it's possible for this to happen for regular register operands, but it may happen in the ARM backend for special operands which use sentinel values for the register (i.e. 0, which is neither a physical register nor a virtual one). This causes MachineInstrExpressionTrait::isEqual (which uses MachineInstr::isIdenticalTo) to return true for the following instructions, which are the same except for the fact that one sets the flags and the other one doesn't: %1114 = ADDrsi %1113, %216, 17, 14, _, def _ %1115 = ADDrsi %1113, %216, 17, 14, _, _ OTOH, MachineInstrExpressionTrait::getHashValue returns different values for the 2 instructions due to the different isDef on the last operand. In practice this means that when trying to add those instructions to a DenseMap, they will be considered different because of their different hash values, but when growing the map we might get an assertion while copying from the old buckets to the new buckets because isEqual misleadingly returns true. This patch makes sure that isEqual and getHashValue agree, by improving the checks in MachineInstr::isIdenticalTo when we are ignoring virtual register definitions (which is what the Trait uses). Firstly, instead of checking isPhysicalRegister, we use !isVirtualRegister, so that we cover both physical registers and sentinel values. Secondly, instead of checking MachineOperand::isReg, we use MachineOperand::isIdenticalTo, which checks isReg, isSubReg and isDef, which are the same values that the hash function uses to compute the hash. Note that the function is symmetric with this change, since if the current operand is not a Def, we check MachineOperand::isIdenticalTo, which returns false if the operands have different isDef's. Differential Revision: https://reviews.llvm.org/D38789 llvm-svn: 315579
2017-10-12 15:59:51 +02:00
#include "llvm/Support/TargetRegistry.h"
#include "llvm/Support/TargetSelect.h"
#include "llvm/Target/TargetMachine.h"
#include "llvm/Target/TargetOptions.h"
#include "gtest/gtest.h"
using namespace llvm;
namespace {
[DebugInfo] Re-implement LexicalScopes dominance method, add unit tests Way back in D24994, the combination of LexicalScopes::dominates and LiveDebugValues was identified as having worst-case quadratic complexity, but it wasn't triggered by any code path at the time. I've since run into a scenario where this occurs, in a very large basic block where large numbers of inlined DBG_VALUEs are present. The quadratic-ness comes from LiveDebugValues::join calling "dominates" on every variable location, and LexicalScopes::dominates potentially touching every instruction in a block to test for the presence of a scope. We have, however, already computed the presence of scopes in blocks, in the "InstrRanges" of each scope. This patch switches the dominates method to examine whether a block is present in a scope's InsnRanges, avoiding walking through the whole block. At the same time, fix getMachineBasicBlocks to account for the fact that InsnRanges can cover multiple blocks, and add some unit tests, as Lexical Scopes didn't have any. Differential revision: https://reviews.llvm.org/D73725
2020-02-28 11:41:23 +01:00
// Include helper functions to ease the manipulation of MachineFunctions.
#include "MFCommon.inc"
MachineInstr: Make isEqual agree with getHashValue in MachineInstrExpressionTrait MachineInstr::isIdenticalTo has a lot of logic for dealing with register Defs (i.e. deciding whether to take them into account or ignore them). This logic gets things wrong in some obscure cases, for instance if an operand is not a Def for both the current MI and the one we are comparing to. I'm not sure if it's possible for this to happen for regular register operands, but it may happen in the ARM backend for special operands which use sentinel values for the register (i.e. 0, which is neither a physical register nor a virtual one). This causes MachineInstrExpressionTrait::isEqual (which uses MachineInstr::isIdenticalTo) to return true for the following instructions, which are the same except for the fact that one sets the flags and the other one doesn't: %1114 = ADDrsi %1113, %216, 17, 14, _, def _ %1115 = ADDrsi %1113, %216, 17, 14, _, _ OTOH, MachineInstrExpressionTrait::getHashValue returns different values for the 2 instructions due to the different isDef on the last operand. In practice this means that when trying to add those instructions to a DenseMap, they will be considered different because of their different hash values, but when growing the map we might get an assertion while copying from the old buckets to the new buckets because isEqual misleadingly returns true. This patch makes sure that isEqual and getHashValue agree, by improving the checks in MachineInstr::isIdenticalTo when we are ignoring virtual register definitions (which is what the Trait uses). Firstly, instead of checking isPhysicalRegister, we use !isVirtualRegister, so that we cover both physical registers and sentinel values. Secondly, instead of checking MachineOperand::isReg, we use MachineOperand::isIdenticalTo, which checks isReg, isSubReg and isDef, which are the same values that the hash function uses to compute the hash. Note that the function is symmetric with this change, since if the current operand is not a Def, we check MachineOperand::isIdenticalTo, which returns false if the operands have different isDef's. Differential Revision: https://reviews.llvm.org/D38789 llvm-svn: 315579
2017-10-12 15:59:51 +02:00
Fix initialization-order-fiasco error in "Add a heap alloc site marker field to the ExtraInfo in MachineInstrs"
2019-10-31 18:48:52 +01:00
std::unique_ptr<MCContext> createMCContext(MCAsmInfo *AsmInfo) {
[MC] Untangle MCContext and MCObjectFileInfo This untangles the MCContext and the MCObjectFileInfo. There is a circular dependency between MCContext and MCObjectFileInfo. Currently this dependency also exists during construction: You can't contruct a MOFI without a MCContext without constructing the MCContext with a dummy version of that MOFI first. This removes this dependency during construction. In a perfect world, MCObjectFileInfo wouldn't depend on MCContext at all, but only be stored in the MCContext, like other MC information. This is future work. This also shifts/adds more information to the MCContext making it more available to the different targets. Namely: - TargetTriple - ObjectFileType - SubtargetInfo Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D101462
2021-05-05 19:03:02 +02:00
Triple TheTriple(/*ArchStr=*/"", /*VendorStr=*/"", /*OSStr=*/"",
/*EnvironmentStr=*/"elf");
return std::make_unique<MCContext>(TheTriple, AsmInfo, nullptr, nullptr,
[MC] Refactor MCObjectFileInfo initialization and allow targets to create MCObjectFileInfo This makes it possible for targets to define their own MCObjectFileInfo. This MCObjectFileInfo is then used to determine things like section alignment. This is a follow up to D101462 and prepares for the RISCV backend defining the text section alignment depending on the enabled extensions. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D101921
2021-05-23 23:15:23 +02:00
nullptr, nullptr, false);
Recommit "Add a heap alloc site marker field to the ExtraInfo in MachineInstrs" Summary: Fixes some things from original commit at https://reviews.llvm.org/D69136. The main change is that the heap alloc marker is always stored as ExtraInfo in the machine instruction instead of in the PointerSumType because it cannot hold more than 4 pointer types. Add instruction marker to MachineInstr ExtraInfo. This does almost the same thing as Pre/PostInstrSymbols, except that it doesn't create a label until printing instructions. This allows for labels to be put around instructions that are deleted/duplicated somewhere. Use this marker to track heap alloc site call instructions. Reviewers: rnk Subscribers: MatzeB, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69536
2019-10-28 22:53:32 +01:00
}
MachineInstr: Make isEqual agree with getHashValue in MachineInstrExpressionTrait MachineInstr::isIdenticalTo has a lot of logic for dealing with register Defs (i.e. deciding whether to take them into account or ignore them). This logic gets things wrong in some obscure cases, for instance if an operand is not a Def for both the current MI and the one we are comparing to. I'm not sure if it's possible for this to happen for regular register operands, but it may happen in the ARM backend for special operands which use sentinel values for the register (i.e. 0, which is neither a physical register nor a virtual one). This causes MachineInstrExpressionTrait::isEqual (which uses MachineInstr::isIdenticalTo) to return true for the following instructions, which are the same except for the fact that one sets the flags and the other one doesn't: %1114 = ADDrsi %1113, %216, 17, 14, _, def _ %1115 = ADDrsi %1113, %216, 17, 14, _, _ OTOH, MachineInstrExpressionTrait::getHashValue returns different values for the 2 instructions due to the different isDef on the last operand. In practice this means that when trying to add those instructions to a DenseMap, they will be considered different because of their different hash values, but when growing the map we might get an assertion while copying from the old buckets to the new buckets because isEqual misleadingly returns true. This patch makes sure that isEqual and getHashValue agree, by improving the checks in MachineInstr::isIdenticalTo when we are ignoring virtual register definitions (which is what the Trait uses). Firstly, instead of checking isPhysicalRegister, we use !isVirtualRegister, so that we cover both physical registers and sentinel values. Secondly, instead of checking MachineOperand::isReg, we use MachineOperand::isIdenticalTo, which checks isReg, isSubReg and isDef, which are the same values that the hash function uses to compute the hash. Note that the function is symmetric with this change, since if the current operand is not a Def, we check MachineOperand::isIdenticalTo, which returns false if the operands have different isDef's. Differential Revision: https://reviews.llvm.org/D38789 llvm-svn: 315579
2017-10-12 15:59:51 +02:00
// This test makes sure that MachineInstr::isIdenticalTo handles Defs correctly
// for various combinations of IgnoreDefs, and also that it is symmetrical.
TEST(IsIdenticalToTest, DifferentDefs) {
[DebugInfo] Re-implement LexicalScopes dominance method, add unit tests Way back in D24994, the combination of LexicalScopes::dominates and LiveDebugValues was identified as having worst-case quadratic complexity, but it wasn't triggered by any code path at the time. I've since run into a scenario where this occurs, in a very large basic block where large numbers of inlined DBG_VALUEs are present. The quadratic-ness comes from LiveDebugValues::join calling "dominates" on every variable location, and LexicalScopes::dominates potentially touching every instruction in a block to test for the presence of a scope. We have, however, already computed the presence of scopes in blocks, in the "InstrRanges" of each scope. This patch switches the dominates method to examine whether a block is present in a scope's InsnRanges, avoiding walking through the whole block. At the same time, fix getMachineBasicBlocks to account for the fact that InsnRanges can cover multiple blocks, and add some unit tests, as Lexical Scopes didn't have any. Differential revision: https://reviews.llvm.org/D73725
2020-02-28 11:41:23 +01:00
LLVMContext Ctx;
Module Mod("Module", Ctx);
auto MF = createMachineFunction(Ctx, Mod);
MachineInstr: Make isEqual agree with getHashValue in MachineInstrExpressionTrait MachineInstr::isIdenticalTo has a lot of logic for dealing with register Defs (i.e. deciding whether to take them into account or ignore them). This logic gets things wrong in some obscure cases, for instance if an operand is not a Def for both the current MI and the one we are comparing to. I'm not sure if it's possible for this to happen for regular register operands, but it may happen in the ARM backend for special operands which use sentinel values for the register (i.e. 0, which is neither a physical register nor a virtual one). This causes MachineInstrExpressionTrait::isEqual (which uses MachineInstr::isIdenticalTo) to return true for the following instructions, which are the same except for the fact that one sets the flags and the other one doesn't: %1114 = ADDrsi %1113, %216, 17, 14, _, def _ %1115 = ADDrsi %1113, %216, 17, 14, _, _ OTOH, MachineInstrExpressionTrait::getHashValue returns different values for the 2 instructions due to the different isDef on the last operand. In practice this means that when trying to add those instructions to a DenseMap, they will be considered different because of their different hash values, but when growing the map we might get an assertion while copying from the old buckets to the new buckets because isEqual misleadingly returns true. This patch makes sure that isEqual and getHashValue agree, by improving the checks in MachineInstr::isIdenticalTo when we are ignoring virtual register definitions (which is what the Trait uses). Firstly, instead of checking isPhysicalRegister, we use !isVirtualRegister, so that we cover both physical registers and sentinel values. Secondly, instead of checking MachineOperand::isReg, we use MachineOperand::isIdenticalTo, which checks isReg, isSubReg and isDef, which are the same values that the hash function uses to compute the hash. Note that the function is symmetric with this change, since if the current operand is not a Def, we check MachineOperand::isIdenticalTo, which returns false if the operands have different isDef's. Differential Revision: https://reviews.llvm.org/D38789 llvm-svn: 315579
2017-10-12 15:59:51 +02:00
unsigned short NumOps = 2;
unsigned char NumDefs = 1;
MCOperandInfo OpInfo[] = {
{0, 0, MCOI::OPERAND_REGISTER, 0},
{0, 1 << MCOI::OptionalDef, MCOI::OPERAND_REGISTER, 0}};
MCInstrDesc MCID = {
[MC] Move deprecation infos from MCTargetDesc to MCInstrInfo This allows emitting it only when the feature is used by a target. Shrinks Release+Asserts clang by 900k.
2020-03-29 21:09:07 +02:00
0, NumOps, NumDefs, 0, 0, 1ULL << MCID::HasOptionalDef,
0, nullptr, nullptr, OpInfo};
MachineInstr: Make isEqual agree with getHashValue in MachineInstrExpressionTrait MachineInstr::isIdenticalTo has a lot of logic for dealing with register Defs (i.e. deciding whether to take them into account or ignore them). This logic gets things wrong in some obscure cases, for instance if an operand is not a Def for both the current MI and the one we are comparing to. I'm not sure if it's possible for this to happen for regular register operands, but it may happen in the ARM backend for special operands which use sentinel values for the register (i.e. 0, which is neither a physical register nor a virtual one). This causes MachineInstrExpressionTrait::isEqual (which uses MachineInstr::isIdenticalTo) to return true for the following instructions, which are the same except for the fact that one sets the flags and the other one doesn't: %1114 = ADDrsi %1113, %216, 17, 14, _, def _ %1115 = ADDrsi %1113, %216, 17, 14, _, _ OTOH, MachineInstrExpressionTrait::getHashValue returns different values for the 2 instructions due to the different isDef on the last operand. In practice this means that when trying to add those instructions to a DenseMap, they will be considered different because of their different hash values, but when growing the map we might get an assertion while copying from the old buckets to the new buckets because isEqual misleadingly returns true. This patch makes sure that isEqual and getHashValue agree, by improving the checks in MachineInstr::isIdenticalTo when we are ignoring virtual register definitions (which is what the Trait uses). Firstly, instead of checking isPhysicalRegister, we use !isVirtualRegister, so that we cover both physical registers and sentinel values. Secondly, instead of checking MachineOperand::isReg, we use MachineOperand::isIdenticalTo, which checks isReg, isSubReg and isDef, which are the same values that the hash function uses to compute the hash. Note that the function is symmetric with this change, since if the current operand is not a Def, we check MachineOperand::isIdenticalTo, which returns false if the operands have different isDef's. Differential Revision: https://reviews.llvm.org/D38789 llvm-svn: 315579
2017-10-12 15:59:51 +02:00
// Create two MIs with different virtual reg defs and the same uses.
unsigned VirtualDef1 = -42; // The value doesn't matter, but the sign does.
unsigned VirtualDef2 = -43;
unsigned VirtualUse = -44;
auto MI1 = MF->CreateMachineInstr(MCID, DebugLoc());
MI1->addOperand(*MF, MachineOperand::CreateReg(VirtualDef1, /*isDef*/ true));
MI1->addOperand(*MF, MachineOperand::CreateReg(VirtualUse, /*isDef*/ false));
auto MI2 = MF->CreateMachineInstr(MCID, DebugLoc());
MI2->addOperand(*MF, MachineOperand::CreateReg(VirtualDef2, /*isDef*/ true));
MI2->addOperand(*MF, MachineOperand::CreateReg(VirtualUse, /*isDef*/ false));
// Check that they are identical when we ignore virtual register defs, but not
// when we check defs.
ASSERT_FALSE(MI1->isIdenticalTo(*MI2, MachineInstr::CheckDefs));
ASSERT_FALSE(MI2->isIdenticalTo(*MI1, MachineInstr::CheckDefs));
ASSERT_TRUE(MI1->isIdenticalTo(*MI2, MachineInstr::IgnoreVRegDefs));
ASSERT_TRUE(MI2->isIdenticalTo(*MI1, MachineInstr::IgnoreVRegDefs));
// Create two MIs with different virtual reg defs, and a def or use of a
// sentinel register.
unsigned SentinelReg = 0;
auto MI3 = MF->CreateMachineInstr(MCID, DebugLoc());
MI3->addOperand(*MF, MachineOperand::CreateReg(VirtualDef1, /*isDef*/ true));
MI3->addOperand(*MF, MachineOperand::CreateReg(SentinelReg, /*isDef*/ true));
auto MI4 = MF->CreateMachineInstr(MCID, DebugLoc());
MI4->addOperand(*MF, MachineOperand::CreateReg(VirtualDef2, /*isDef*/ true));
MI4->addOperand(*MF, MachineOperand::CreateReg(SentinelReg, /*isDef*/ false));
// Check that they are never identical.
ASSERT_FALSE(MI3->isIdenticalTo(*MI4, MachineInstr::CheckDefs));
ASSERT_FALSE(MI4->isIdenticalTo(*MI3, MachineInstr::CheckDefs));
ASSERT_FALSE(MI3->isIdenticalTo(*MI4, MachineInstr::IgnoreVRegDefs));
ASSERT_FALSE(MI4->isIdenticalTo(*MI3, MachineInstr::IgnoreVRegDefs));
}
// Check that MachineInstrExpressionTrait::isEqual is symmetric and in sync with
// MachineInstrExpressionTrait::getHashValue
void checkHashAndIsEqualMatch(MachineInstr *MI1, MachineInstr *MI2) {
bool IsEqual1 = MachineInstrExpressionTrait::isEqual(MI1, MI2);
bool IsEqual2 = MachineInstrExpressionTrait::isEqual(MI2, MI1);
ASSERT_EQ(IsEqual1, IsEqual2);
auto Hash1 = MachineInstrExpressionTrait::getHashValue(MI1);
auto Hash2 = MachineInstrExpressionTrait::getHashValue(MI2);
ASSERT_EQ(IsEqual1, Hash1 == Hash2);
}
// This test makes sure that MachineInstrExpressionTraits::isEqual is in sync
// with MachineInstrExpressionTraits::getHashValue.
TEST(MachineInstrExpressionTraitTest, IsEqualAgreesWithGetHashValue) {
[DebugInfo] Re-implement LexicalScopes dominance method, add unit tests Way back in D24994, the combination of LexicalScopes::dominates and LiveDebugValues was identified as having worst-case quadratic complexity, but it wasn't triggered by any code path at the time. I've since run into a scenario where this occurs, in a very large basic block where large numbers of inlined DBG_VALUEs are present. The quadratic-ness comes from LiveDebugValues::join calling "dominates" on every variable location, and LexicalScopes::dominates potentially touching every instruction in a block to test for the presence of a scope. We have, however, already computed the presence of scopes in blocks, in the "InstrRanges" of each scope. This patch switches the dominates method to examine whether a block is present in a scope's InsnRanges, avoiding walking through the whole block. At the same time, fix getMachineBasicBlocks to account for the fact that InsnRanges can cover multiple blocks, and add some unit tests, as Lexical Scopes didn't have any. Differential revision: https://reviews.llvm.org/D73725
2020-02-28 11:41:23 +01:00
LLVMContext Ctx;
Module Mod("Module", Ctx);
auto MF = createMachineFunction(Ctx, Mod);
MachineInstr: Make isEqual agree with getHashValue in MachineInstrExpressionTrait MachineInstr::isIdenticalTo has a lot of logic for dealing with register Defs (i.e. deciding whether to take them into account or ignore them). This logic gets things wrong in some obscure cases, for instance if an operand is not a Def for both the current MI and the one we are comparing to. I'm not sure if it's possible for this to happen for regular register operands, but it may happen in the ARM backend for special operands which use sentinel values for the register (i.e. 0, which is neither a physical register nor a virtual one). This causes MachineInstrExpressionTrait::isEqual (which uses MachineInstr::isIdenticalTo) to return true for the following instructions, which are the same except for the fact that one sets the flags and the other one doesn't: %1114 = ADDrsi %1113, %216, 17, 14, _, def _ %1115 = ADDrsi %1113, %216, 17, 14, _, _ OTOH, MachineInstrExpressionTrait::getHashValue returns different values for the 2 instructions due to the different isDef on the last operand. In practice this means that when trying to add those instructions to a DenseMap, they will be considered different because of their different hash values, but when growing the map we might get an assertion while copying from the old buckets to the new buckets because isEqual misleadingly returns true. This patch makes sure that isEqual and getHashValue agree, by improving the checks in MachineInstr::isIdenticalTo when we are ignoring virtual register definitions (which is what the Trait uses). Firstly, instead of checking isPhysicalRegister, we use !isVirtualRegister, so that we cover both physical registers and sentinel values. Secondly, instead of checking MachineOperand::isReg, we use MachineOperand::isIdenticalTo, which checks isReg, isSubReg and isDef, which are the same values that the hash function uses to compute the hash. Note that the function is symmetric with this change, since if the current operand is not a Def, we check MachineOperand::isIdenticalTo, which returns false if the operands have different isDef's. Differential Revision: https://reviews.llvm.org/D38789 llvm-svn: 315579
2017-10-12 15:59:51 +02:00
unsigned short NumOps = 2;
unsigned char NumDefs = 1;
MCOperandInfo OpInfo[] = {
{0, 0, MCOI::OPERAND_REGISTER, 0},
{0, 1 << MCOI::OptionalDef, MCOI::OPERAND_REGISTER, 0}};
MCInstrDesc MCID = {
[MC] Move deprecation infos from MCTargetDesc to MCInstrInfo This allows emitting it only when the feature is used by a target. Shrinks Release+Asserts clang by 900k.
2020-03-29 21:09:07 +02:00
0, NumOps, NumDefs, 0, 0, 1ULL << MCID::HasOptionalDef,
0, nullptr, nullptr, OpInfo};
MachineInstr: Make isEqual agree with getHashValue in MachineInstrExpressionTrait MachineInstr::isIdenticalTo has a lot of logic for dealing with register Defs (i.e. deciding whether to take them into account or ignore them). This logic gets things wrong in some obscure cases, for instance if an operand is not a Def for both the current MI and the one we are comparing to. I'm not sure if it's possible for this to happen for regular register operands, but it may happen in the ARM backend for special operands which use sentinel values for the register (i.e. 0, which is neither a physical register nor a virtual one). This causes MachineInstrExpressionTrait::isEqual (which uses MachineInstr::isIdenticalTo) to return true for the following instructions, which are the same except for the fact that one sets the flags and the other one doesn't: %1114 = ADDrsi %1113, %216, 17, 14, _, def _ %1115 = ADDrsi %1113, %216, 17, 14, _, _ OTOH, MachineInstrExpressionTrait::getHashValue returns different values for the 2 instructions due to the different isDef on the last operand. In practice this means that when trying to add those instructions to a DenseMap, they will be considered different because of their different hash values, but when growing the map we might get an assertion while copying from the old buckets to the new buckets because isEqual misleadingly returns true. This patch makes sure that isEqual and getHashValue agree, by improving the checks in MachineInstr::isIdenticalTo when we are ignoring virtual register definitions (which is what the Trait uses). Firstly, instead of checking isPhysicalRegister, we use !isVirtualRegister, so that we cover both physical registers and sentinel values. Secondly, instead of checking MachineOperand::isReg, we use MachineOperand::isIdenticalTo, which checks isReg, isSubReg and isDef, which are the same values that the hash function uses to compute the hash. Note that the function is symmetric with this change, since if the current operand is not a Def, we check MachineOperand::isIdenticalTo, which returns false if the operands have different isDef's. Differential Revision: https://reviews.llvm.org/D38789 llvm-svn: 315579
2017-10-12 15:59:51 +02:00
// Define a series of instructions with different kinds of operands and make
// sure that the hash function is consistent with isEqual for various
// combinations of them.
unsigned VirtualDef1 = -42;
unsigned VirtualDef2 = -43;
unsigned VirtualReg = -44;
unsigned SentinelReg = 0;
unsigned PhysicalReg = 45;
auto VD1VU = MF->CreateMachineInstr(MCID, DebugLoc());
VD1VU->addOperand(*MF,
MachineOperand::CreateReg(VirtualDef1, /*isDef*/ true));
VD1VU->addOperand(*MF,
MachineOperand::CreateReg(VirtualReg, /*isDef*/ false));
auto VD2VU = MF->CreateMachineInstr(MCID, DebugLoc());
VD2VU->addOperand(*MF,
MachineOperand::CreateReg(VirtualDef2, /*isDef*/ true));
VD2VU->addOperand(*MF,
MachineOperand::CreateReg(VirtualReg, /*isDef*/ false));
auto VD1SU = MF->CreateMachineInstr(MCID, DebugLoc());
VD1SU->addOperand(*MF,
MachineOperand::CreateReg(VirtualDef1, /*isDef*/ true));
VD1SU->addOperand(*MF,
MachineOperand::CreateReg(SentinelReg, /*isDef*/ false));
auto VD1SD = MF->CreateMachineInstr(MCID, DebugLoc());
VD1SD->addOperand(*MF,
MachineOperand::CreateReg(VirtualDef1, /*isDef*/ true));
VD1SD->addOperand(*MF,
MachineOperand::CreateReg(SentinelReg, /*isDef*/ true));
auto VD2PU = MF->CreateMachineInstr(MCID, DebugLoc());
VD2PU->addOperand(*MF,
MachineOperand::CreateReg(VirtualDef2, /*isDef*/ true));
VD2PU->addOperand(*MF,
MachineOperand::CreateReg(PhysicalReg, /*isDef*/ false));
auto VD2PD = MF->CreateMachineInstr(MCID, DebugLoc());
VD2PD->addOperand(*MF,
MachineOperand::CreateReg(VirtualDef2, /*isDef*/ true));
VD2PD->addOperand(*MF,
MachineOperand::CreateReg(PhysicalReg, /*isDef*/ true));
checkHashAndIsEqualMatch(VD1VU, VD2VU);
checkHashAndIsEqualMatch(VD1VU, VD1SU);
checkHashAndIsEqualMatch(VD1VU, VD1SD);
checkHashAndIsEqualMatch(VD1VU, VD2PU);
checkHashAndIsEqualMatch(VD1VU, VD2PD);
checkHashAndIsEqualMatch(VD2VU, VD1SU);
checkHashAndIsEqualMatch(VD2VU, VD1SD);
checkHashAndIsEqualMatch(VD2VU, VD2PU);
checkHashAndIsEqualMatch(VD2VU, VD2PD);
checkHashAndIsEqualMatch(VD1SU, VD1SD);
checkHashAndIsEqualMatch(VD1SU, VD2PU);
checkHashAndIsEqualMatch(VD1SU, VD2PD);
checkHashAndIsEqualMatch(VD1SD, VD2PU);
checkHashAndIsEqualMatch(VD1SD, VD2PD);
checkHashAndIsEqualMatch(VD2PU, VD2PD);
}
[CodeGen] Unify printing format of debug-location in both MIR and -debug Use "debug-location" instead of "; dbg:" in MI::print. llvm-svn: 322936
2018-01-19 12:44:42 +01:00
TEST(MachineInstrPrintingTest, DebugLocPrinting) {
[DebugInfo] Re-implement LexicalScopes dominance method, add unit tests Way back in D24994, the combination of LexicalScopes::dominates and LiveDebugValues was identified as having worst-case quadratic complexity, but it wasn't triggered by any code path at the time. I've since run into a scenario where this occurs, in a very large basic block where large numbers of inlined DBG_VALUEs are present. The quadratic-ness comes from LiveDebugValues::join calling "dominates" on every variable location, and LexicalScopes::dominates potentially touching every instruction in a block to test for the presence of a scope. We have, however, already computed the presence of scopes in blocks, in the "InstrRanges" of each scope. This patch switches the dominates method to examine whether a block is present in a scope's InsnRanges, avoiding walking through the whole block. At the same time, fix getMachineBasicBlocks to account for the fact that InsnRanges can cover multiple blocks, and add some unit tests, as Lexical Scopes didn't have any. Differential revision: https://reviews.llvm.org/D73725
2020-02-28 11:41:23 +01:00
LLVMContext Ctx;
Module Mod("Module", Ctx);
auto MF = createMachineFunction(Ctx, Mod);
[CodeGen] Unify printing format of debug-location in both MIR and -debug Use "debug-location" instead of "; dbg:" in MI::print. llvm-svn: 322936
2018-01-19 12:44:42 +01:00
MCOperandInfo OpInfo{0, 0, MCOI::OPERAND_REGISTER, 0};
[MC] Move deprecation infos from MCTargetDesc to MCInstrInfo This allows emitting it only when the feature is used by a target. Shrinks Release+Asserts clang by 900k.
2020-03-29 21:09:07 +02:00
MCInstrDesc MCID = {0, 1, 1, 0, 0, 0, 0, nullptr, nullptr, &OpInfo};
[CodeGen] Unify printing format of debug-location in both MIR and -debug Use "debug-location" instead of "; dbg:" in MI::print. llvm-svn: 322936
2018-01-19 12:44:42 +01:00
[CodeGen] Print user-friendly debug locations as MI comments If available, print the file, line and column of the DebugLoc attached to the MachineInstr: MOV16mr $rbp, 1, $noreg, -112, $noreg, killed renamable $ax, debug-location !56 :: (store 2 into %ir.._value12); stepping.swift:10:17 renamable $edx = MOVZX32rm16 $rbp, 1, $noreg, -112, $noreg, debug-location !62 :: (dereferenceable load 2 from %ir.._value13); stepping.swift:10:17 Differential Revision: https://reviews.llvm.org/D45992 llvm-svn: 330709
2018-04-24 13:00:46 +02:00
DIFile *DIF = DIFile::getDistinct(Ctx, "filename", "");
DISubprogram *DIS = DISubprogram::getDistinct(
[DebugInfo] DISubprogram flags get their own flags word. NFC. This will hold flags specific to subprograms. In the future we could potentially free up scarce bits in DIFlags by moving subprogram-specific flags from there to the new flags word. This patch does not change IR/bitcode formats, that will be done in a follow-up. Differential Revision: https://reviews.llvm.org/D54597 llvm-svn: 347239
2018-11-19 19:29:28 +01:00
Ctx, nullptr, "", "", DIF, 0, nullptr, 0, nullptr, 0, 0, DINode::FlagZero,
DISubprogram::SPFlagZero, nullptr);
[CodeGen] Print user-friendly debug locations as MI comments If available, print the file, line and column of the DebugLoc attached to the MachineInstr: MOV16mr $rbp, 1, $noreg, -112, $noreg, killed renamable $ax, debug-location !56 :: (store 2 into %ir.._value12); stepping.swift:10:17 renamable $edx = MOVZX32rm16 $rbp, 1, $noreg, -112, $noreg, debug-location !62 :: (dereferenceable load 2 from %ir.._value13); stepping.swift:10:17 Differential Revision: https://reviews.llvm.org/D45992 llvm-svn: 330709
2018-04-24 13:00:46 +02:00
DILocation *DIL = DILocation::get(Ctx, 1, 5, DIS);
[CodeGen] Unify printing format of debug-location in both MIR and -debug Use "debug-location" instead of "; dbg:" in MI::print. llvm-svn: 322936
2018-01-19 12:44:42 +01:00
DebugLoc DL(DIL);
MachineInstr *MI = MF->CreateMachineInstr(MCID, DL);
MI->addOperand(*MF, MachineOperand::CreateReg(0, /*isDef*/ true));
std::string str;
raw_string_ostream OS(str);
[X86] Fix several places that weren't passing what they though they were to MachineInstr::print Over a year ago, MachineInstr gained a fourth boolean parameter that occurs before the TII pointer. When this happened, several places started accidentally passing TII into this boolean parameter instead of the TII parameter. llvm-svn: 362312
2019-06-02 03:36:48 +02:00
MI->print(OS, /*IsStandalone*/true, /*SkipOpers*/false, /*SkipDebugLoc*/false,
/*AddNewLine*/false);
[CodeGen] Unify printing format of debug-location in both MIR and -debug Use "debug-location" instead of "; dbg:" in MI::print. llvm-svn: 322936
2018-01-19 12:44:42 +01:00
ASSERT_TRUE(
Followup on Proposal to move MIR physical register namespace to '$' sigil. Discussed here: http://lists.llvm.org/pipermail/llvm-dev/2018-January/120320.html In preparation for adding support for named vregs we are changing the sigil for physical registers in MIR to '$' from '%'. This will prevent name clashes of named physical register with named vregs. llvm-svn: 323922
2018-01-31 23:04:26 +01:00
StringRef(OS.str()).startswith("$noreg = UNKNOWN debug-location "));
[CodeGen] Print user-friendly debug locations as MI comments If available, print the file, line and column of the DebugLoc attached to the MachineInstr: MOV16mr $rbp, 1, $noreg, -112, $noreg, killed renamable $ax, debug-location !56 :: (store 2 into %ir.._value12); stepping.swift:10:17 renamable $edx = MOVZX32rm16 $rbp, 1, $noreg, -112, $noreg, debug-location !62 :: (dereferenceable load 2 from %ir.._value13); stepping.swift:10:17 Differential Revision: https://reviews.llvm.org/D45992 llvm-svn: 330709
2018-04-24 13:00:46 +02:00
ASSERT_TRUE(
StringRef(OS.str()).endswith("filename:1:5"));
[CodeGen] Unify printing format of debug-location in both MIR and -debug Use "debug-location" instead of "; dbg:" in MI::print. llvm-svn: 322936
2018-01-19 12:44:42 +01:00
}
[CodeGen] Enhance `MachineInstrSpan` to allow the end of MBB to be used. Summary: - Explicitly specify the parent MBB to allow the end iterator to be used. Reviewers: aprantl, MatzeB, craig.topper, qcolombet Subscribers: arsenm, jvesely, nhaehnle, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64261 llvm-svn: 365240
2019-07-05 22:23:59 +02:00
TEST(MachineInstrSpan, DistanceBegin) {
[DebugInfo] Re-implement LexicalScopes dominance method, add unit tests Way back in D24994, the combination of LexicalScopes::dominates and LiveDebugValues was identified as having worst-case quadratic complexity, but it wasn't triggered by any code path at the time. I've since run into a scenario where this occurs, in a very large basic block where large numbers of inlined DBG_VALUEs are present. The quadratic-ness comes from LiveDebugValues::join calling "dominates" on every variable location, and LexicalScopes::dominates potentially touching every instruction in a block to test for the presence of a scope. We have, however, already computed the presence of scopes in blocks, in the "InstrRanges" of each scope. This patch switches the dominates method to examine whether a block is present in a scope's InsnRanges, avoiding walking through the whole block. At the same time, fix getMachineBasicBlocks to account for the fact that InsnRanges can cover multiple blocks, and add some unit tests, as Lexical Scopes didn't have any. Differential revision: https://reviews.llvm.org/D73725
2020-02-28 11:41:23 +01:00
LLVMContext Ctx;
Module Mod("Module", Ctx);
auto MF = createMachineFunction(Ctx, Mod);
[CodeGen] Enhance `MachineInstrSpan` to allow the end of MBB to be used. Summary: - Explicitly specify the parent MBB to allow the end iterator to be used. Reviewers: aprantl, MatzeB, craig.topper, qcolombet Subscribers: arsenm, jvesely, nhaehnle, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64261 llvm-svn: 365240
2019-07-05 22:23:59 +02:00
auto MBB = MF->CreateMachineBasicBlock();
[MC] Move deprecation infos from MCTargetDesc to MCInstrInfo This allows emitting it only when the feature is used by a target. Shrinks Release+Asserts clang by 900k.
2020-03-29 21:09:07 +02:00
MCInstrDesc MCID = {0, 0, 0, 0, 0, 0, 0, nullptr, nullptr, nullptr};
[CodeGen] Enhance `MachineInstrSpan` to allow the end of MBB to be used. Summary: - Explicitly specify the parent MBB to allow the end iterator to be used. Reviewers: aprantl, MatzeB, craig.topper, qcolombet Subscribers: arsenm, jvesely, nhaehnle, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64261 llvm-svn: 365240
2019-07-05 22:23:59 +02:00
auto MII = MBB->begin();
MachineInstrSpan MIS(MII, MBB);
ASSERT_TRUE(MIS.empty());
auto MI = MF->CreateMachineInstr(MCID, DebugLoc());
MBB->insert(MII, MI);
ASSERT_TRUE(std::distance(MIS.begin(), MII) == 1);
}
TEST(MachineInstrSpan, DistanceEnd) {
[DebugInfo] Re-implement LexicalScopes dominance method, add unit tests Way back in D24994, the combination of LexicalScopes::dominates and LiveDebugValues was identified as having worst-case quadratic complexity, but it wasn't triggered by any code path at the time. I've since run into a scenario where this occurs, in a very large basic block where large numbers of inlined DBG_VALUEs are present. The quadratic-ness comes from LiveDebugValues::join calling "dominates" on every variable location, and LexicalScopes::dominates potentially touching every instruction in a block to test for the presence of a scope. We have, however, already computed the presence of scopes in blocks, in the "InstrRanges" of each scope. This patch switches the dominates method to examine whether a block is present in a scope's InsnRanges, avoiding walking through the whole block. At the same time, fix getMachineBasicBlocks to account for the fact that InsnRanges can cover multiple blocks, and add some unit tests, as Lexical Scopes didn't have any. Differential revision: https://reviews.llvm.org/D73725
2020-02-28 11:41:23 +01:00
LLVMContext Ctx;
Module Mod("Module", Ctx);
auto MF = createMachineFunction(Ctx, Mod);
[CodeGen] Enhance `MachineInstrSpan` to allow the end of MBB to be used. Summary: - Explicitly specify the parent MBB to allow the end iterator to be used. Reviewers: aprantl, MatzeB, craig.topper, qcolombet Subscribers: arsenm, jvesely, nhaehnle, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64261 llvm-svn: 365240
2019-07-05 22:23:59 +02:00
auto MBB = MF->CreateMachineBasicBlock();
[MC] Move deprecation infos from MCTargetDesc to MCInstrInfo This allows emitting it only when the feature is used by a target. Shrinks Release+Asserts clang by 900k.
2020-03-29 21:09:07 +02:00
MCInstrDesc MCID = {0, 0, 0, 0, 0, 0, 0, nullptr, nullptr, nullptr};
[CodeGen] Enhance `MachineInstrSpan` to allow the end of MBB to be used. Summary: - Explicitly specify the parent MBB to allow the end iterator to be used. Reviewers: aprantl, MatzeB, craig.topper, qcolombet Subscribers: arsenm, jvesely, nhaehnle, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64261 llvm-svn: 365240
2019-07-05 22:23:59 +02:00
auto MII = MBB->end();
MachineInstrSpan MIS(MII, MBB);
ASSERT_TRUE(MIS.empty());
auto MI = MF->CreateMachineInstr(MCID, DebugLoc());
MBB->insert(MII, MI);
ASSERT_TRUE(std::distance(MIS.begin(), MII) == 1);
}
Recommit "Add a heap alloc site marker field to the ExtraInfo in MachineInstrs" Summary: Fixes some things from original commit at https://reviews.llvm.org/D69136. The main change is that the heap alloc marker is always stored as ExtraInfo in the machine instruction instead of in the PointerSumType because it cannot hold more than 4 pointer types. Add instruction marker to MachineInstr ExtraInfo. This does almost the same thing as Pre/PostInstrSymbols, except that it doesn't create a label until printing instructions. This allows for labels to be put around instructions that are deleted/duplicated somewhere. Use this marker to track heap alloc site call instructions. Reviewers: rnk Subscribers: MatzeB, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69536
2019-10-28 22:53:32 +01:00
TEST(MachineInstrExtraInfo, AddExtraInfo) {
[DebugInfo] Re-implement LexicalScopes dominance method, add unit tests Way back in D24994, the combination of LexicalScopes::dominates and LiveDebugValues was identified as having worst-case quadratic complexity, but it wasn't triggered by any code path at the time. I've since run into a scenario where this occurs, in a very large basic block where large numbers of inlined DBG_VALUEs are present. The quadratic-ness comes from LiveDebugValues::join calling "dominates" on every variable location, and LexicalScopes::dominates potentially touching every instruction in a block to test for the presence of a scope. We have, however, already computed the presence of scopes in blocks, in the "InstrRanges" of each scope. This patch switches the dominates method to examine whether a block is present in a scope's InsnRanges, avoiding walking through the whole block. At the same time, fix getMachineBasicBlocks to account for the fact that InsnRanges can cover multiple blocks, and add some unit tests, as Lexical Scopes didn't have any. Differential revision: https://reviews.llvm.org/D73725
2020-02-28 11:41:23 +01:00
LLVMContext Ctx;
Module Mod("Module", Ctx);
auto MF = createMachineFunction(Ctx, Mod);
[MC] Move deprecation infos from MCTargetDesc to MCInstrInfo This allows emitting it only when the feature is used by a target. Shrinks Release+Asserts clang by 900k.
2020-03-29 21:09:07 +02:00
MCInstrDesc MCID = {0, 0, 0, 0, 0, 0, 0, nullptr, nullptr, nullptr};
Recommit "Add a heap alloc site marker field to the ExtraInfo in MachineInstrs" Summary: Fixes some things from original commit at https://reviews.llvm.org/D69136. The main change is that the heap alloc marker is always stored as ExtraInfo in the machine instruction instead of in the PointerSumType because it cannot hold more than 4 pointer types. Add instruction marker to MachineInstr ExtraInfo. This does almost the same thing as Pre/PostInstrSymbols, except that it doesn't create a label until printing instructions. This allows for labels to be put around instructions that are deleted/duplicated somewhere. Use this marker to track heap alloc site call instructions. Reviewers: rnk Subscribers: MatzeB, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69536
2019-10-28 22:53:32 +01:00
auto MI = MF->CreateMachineInstr(MCID, DebugLoc());
Fix initialization-order-fiasco error in "Add a heap alloc site marker field to the ExtraInfo in MachineInstrs"
2019-10-31 18:48:52 +01:00
auto MAI = MCAsmInfo();
auto MC = createMCContext(&MAI);
Recommit "Add a heap alloc site marker field to the ExtraInfo in MachineInstrs" Summary: Fixes some things from original commit at https://reviews.llvm.org/D69136. The main change is that the heap alloc marker is always stored as ExtraInfo in the machine instruction instead of in the PointerSumType because it cannot hold more than 4 pointer types. Add instruction marker to MachineInstr ExtraInfo. This does almost the same thing as Pre/PostInstrSymbols, except that it doesn't create a label until printing instructions. This allows for labels to be put around instructions that are deleted/duplicated somewhere. Use this marker to track heap alloc site call instructions. Reviewers: rnk Subscribers: MatzeB, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69536
2019-10-28 22:53:32 +01:00
auto MMO = MF->getMachineMemOperand(MachinePointerInfo(),
[Alignment][NFC] Use Align version of getMachineMemOperand Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Subscribers: jyknight, sdardis, nemanjai, hiraditya, kbarton, fedor.sergeev, asb, rbar, johnrusso, simoncook, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, rogfer01, MartinMosbeck, brucehoult, the_o, jfb, PkmX, jocewei, Jim, lenary, s.egerton, pzheng, sameer.abuasal, apazos, luismarques, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D77059
2020-03-30 16:45:57 +02:00
MachineMemOperand::MOLoad, 8, Align(8));
Recommit "Add a heap alloc site marker field to the ExtraInfo in MachineInstrs" Summary: Fixes some things from original commit at https://reviews.llvm.org/D69136. The main change is that the heap alloc marker is always stored as ExtraInfo in the machine instruction instead of in the PointerSumType because it cannot hold more than 4 pointer types. Add instruction marker to MachineInstr ExtraInfo. This does almost the same thing as Pre/PostInstrSymbols, except that it doesn't create a label until printing instructions. This allows for labels to be put around instructions that are deleted/duplicated somewhere. Use this marker to track heap alloc site call instructions. Reviewers: rnk Subscribers: MatzeB, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69536
2019-10-28 22:53:32 +01:00
SmallVector<MachineMemOperand *, 2> MMOs;
MMOs.push_back(MMO);
MCSymbol *Sym1 = MC->createTempSymbol("pre_label", false);
MCSymbol *Sym2 = MC->createTempSymbol("post_label", false);
MDNode *MDN = MDNode::getDistinct(Ctx, None);
ASSERT_TRUE(MI->memoperands_empty());
ASSERT_FALSE(MI->getPreInstrSymbol());
ASSERT_FALSE(MI->getPostInstrSymbol());
ASSERT_FALSE(MI->getHeapAllocMarker());
MI->setMemRefs(*MF, MMOs);
ASSERT_TRUE(MI->memoperands().size() == 1);
ASSERT_FALSE(MI->getPreInstrSymbol());
ASSERT_FALSE(MI->getPostInstrSymbol());
ASSERT_FALSE(MI->getHeapAllocMarker());
MI->setPreInstrSymbol(*MF, Sym1);
ASSERT_TRUE(MI->memoperands().size() == 1);
ASSERT_TRUE(MI->getPreInstrSymbol() == Sym1);
ASSERT_FALSE(MI->getPostInstrSymbol());
ASSERT_FALSE(MI->getHeapAllocMarker());
MI->setPostInstrSymbol(*MF, Sym2);
ASSERT_TRUE(MI->memoperands().size() == 1);
ASSERT_TRUE(MI->getPreInstrSymbol() == Sym1);
ASSERT_TRUE(MI->getPostInstrSymbol() == Sym2);
ASSERT_FALSE(MI->getHeapAllocMarker());
MI->setHeapAllocMarker(*MF, MDN);
ASSERT_TRUE(MI->memoperands().size() == 1);
ASSERT_TRUE(MI->getPreInstrSymbol() == Sym1);
ASSERT_TRUE(MI->getPostInstrSymbol() == Sym2);
ASSERT_TRUE(MI->getHeapAllocMarker() == MDN);
}
TEST(MachineInstrExtraInfo, ChangeExtraInfo) {
[DebugInfo] Re-implement LexicalScopes dominance method, add unit tests Way back in D24994, the combination of LexicalScopes::dominates and LiveDebugValues was identified as having worst-case quadratic complexity, but it wasn't triggered by any code path at the time. I've since run into a scenario where this occurs, in a very large basic block where large numbers of inlined DBG_VALUEs are present. The quadratic-ness comes from LiveDebugValues::join calling "dominates" on every variable location, and LexicalScopes::dominates potentially touching every instruction in a block to test for the presence of a scope. We have, however, already computed the presence of scopes in blocks, in the "InstrRanges" of each scope. This patch switches the dominates method to examine whether a block is present in a scope's InsnRanges, avoiding walking through the whole block. At the same time, fix getMachineBasicBlocks to account for the fact that InsnRanges can cover multiple blocks, and add some unit tests, as Lexical Scopes didn't have any. Differential revision: https://reviews.llvm.org/D73725
2020-02-28 11:41:23 +01:00
LLVMContext Ctx;
Module Mod("Module", Ctx);
auto MF = createMachineFunction(Ctx, Mod);
[MC] Move deprecation infos from MCTargetDesc to MCInstrInfo This allows emitting it only when the feature is used by a target. Shrinks Release+Asserts clang by 900k.
2020-03-29 21:09:07 +02:00
MCInstrDesc MCID = {0, 0, 0, 0, 0, 0, 0, nullptr, nullptr, nullptr};
Recommit "Add a heap alloc site marker field to the ExtraInfo in MachineInstrs" Summary: Fixes some things from original commit at https://reviews.llvm.org/D69136. The main change is that the heap alloc marker is always stored as ExtraInfo in the machine instruction instead of in the PointerSumType because it cannot hold more than 4 pointer types. Add instruction marker to MachineInstr ExtraInfo. This does almost the same thing as Pre/PostInstrSymbols, except that it doesn't create a label until printing instructions. This allows for labels to be put around instructions that are deleted/duplicated somewhere. Use this marker to track heap alloc site call instructions. Reviewers: rnk Subscribers: MatzeB, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69536
2019-10-28 22:53:32 +01:00
auto MI = MF->CreateMachineInstr(MCID, DebugLoc());
Fix initialization-order-fiasco error in "Add a heap alloc site marker field to the ExtraInfo in MachineInstrs"
2019-10-31 18:48:52 +01:00
auto MAI = MCAsmInfo();
auto MC = createMCContext(&MAI);
Recommit "Add a heap alloc site marker field to the ExtraInfo in MachineInstrs" Summary: Fixes some things from original commit at https://reviews.llvm.org/D69136. The main change is that the heap alloc marker is always stored as ExtraInfo in the machine instruction instead of in the PointerSumType because it cannot hold more than 4 pointer types. Add instruction marker to MachineInstr ExtraInfo. This does almost the same thing as Pre/PostInstrSymbols, except that it doesn't create a label until printing instructions. This allows for labels to be put around instructions that are deleted/duplicated somewhere. Use this marker to track heap alloc site call instructions. Reviewers: rnk Subscribers: MatzeB, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69536
2019-10-28 22:53:32 +01:00
auto MMO = MF->getMachineMemOperand(MachinePointerInfo(),
[Alignment][NFC] Use Align version of getMachineMemOperand Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Subscribers: jyknight, sdardis, nemanjai, hiraditya, kbarton, fedor.sergeev, asb, rbar, johnrusso, simoncook, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, rogfer01, MartinMosbeck, brucehoult, the_o, jfb, PkmX, jocewei, Jim, lenary, s.egerton, pzheng, sameer.abuasal, apazos, luismarques, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D77059
2020-03-30 16:45:57 +02:00
MachineMemOperand::MOLoad, 8, Align(8));
Recommit "Add a heap alloc site marker field to the ExtraInfo in MachineInstrs" Summary: Fixes some things from original commit at https://reviews.llvm.org/D69136. The main change is that the heap alloc marker is always stored as ExtraInfo in the machine instruction instead of in the PointerSumType because it cannot hold more than 4 pointer types. Add instruction marker to MachineInstr ExtraInfo. This does almost the same thing as Pre/PostInstrSymbols, except that it doesn't create a label until printing instructions. This allows for labels to be put around instructions that are deleted/duplicated somewhere. Use this marker to track heap alloc site call instructions. Reviewers: rnk Subscribers: MatzeB, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69536
2019-10-28 22:53:32 +01:00
SmallVector<MachineMemOperand *, 2> MMOs;
MMOs.push_back(MMO);
MCSymbol *Sym1 = MC->createTempSymbol("pre_label", false);
MCSymbol *Sym2 = MC->createTempSymbol("post_label", false);
MDNode *MDN = MDNode::getDistinct(Ctx, None);
MI->setMemRefs(*MF, MMOs);
MI->setPreInstrSymbol(*MF, Sym1);
MI->setPostInstrSymbol(*MF, Sym2);
MI->setHeapAllocMarker(*MF, MDN);
MMOs.push_back(MMO);
MI->setMemRefs(*MF, MMOs);
ASSERT_TRUE(MI->memoperands().size() == 2);
ASSERT_TRUE(MI->getPreInstrSymbol() == Sym1);
ASSERT_TRUE(MI->getPostInstrSymbol() == Sym2);
ASSERT_TRUE(MI->getHeapAllocMarker() == MDN);
MI->setPostInstrSymbol(*MF, Sym1);
ASSERT_TRUE(MI->memoperands().size() == 2);
ASSERT_TRUE(MI->getPreInstrSymbol() == Sym1);
ASSERT_TRUE(MI->getPostInstrSymbol() == Sym1);
ASSERT_TRUE(MI->getHeapAllocMarker() == MDN);
}
TEST(MachineInstrExtraInfo, RemoveExtraInfo) {
[DebugInfo] Re-implement LexicalScopes dominance method, add unit tests Way back in D24994, the combination of LexicalScopes::dominates and LiveDebugValues was identified as having worst-case quadratic complexity, but it wasn't triggered by any code path at the time. I've since run into a scenario where this occurs, in a very large basic block where large numbers of inlined DBG_VALUEs are present. The quadratic-ness comes from LiveDebugValues::join calling "dominates" on every variable location, and LexicalScopes::dominates potentially touching every instruction in a block to test for the presence of a scope. We have, however, already computed the presence of scopes in blocks, in the "InstrRanges" of each scope. This patch switches the dominates method to examine whether a block is present in a scope's InsnRanges, avoiding walking through the whole block. At the same time, fix getMachineBasicBlocks to account for the fact that InsnRanges can cover multiple blocks, and add some unit tests, as Lexical Scopes didn't have any. Differential revision: https://reviews.llvm.org/D73725
2020-02-28 11:41:23 +01:00
LLVMContext Ctx;
Module Mod("Module", Ctx);
auto MF = createMachineFunction(Ctx, Mod);
[MC] Move deprecation infos from MCTargetDesc to MCInstrInfo This allows emitting it only when the feature is used by a target. Shrinks Release+Asserts clang by 900k.
2020-03-29 21:09:07 +02:00
MCInstrDesc MCID = {0, 0, 0, 0, 0, 0, 0, nullptr, nullptr, nullptr};
Recommit "Add a heap alloc site marker field to the ExtraInfo in MachineInstrs" Summary: Fixes some things from original commit at https://reviews.llvm.org/D69136. The main change is that the heap alloc marker is always stored as ExtraInfo in the machine instruction instead of in the PointerSumType because it cannot hold more than 4 pointer types. Add instruction marker to MachineInstr ExtraInfo. This does almost the same thing as Pre/PostInstrSymbols, except that it doesn't create a label until printing instructions. This allows for labels to be put around instructions that are deleted/duplicated somewhere. Use this marker to track heap alloc site call instructions. Reviewers: rnk Subscribers: MatzeB, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69536
2019-10-28 22:53:32 +01:00
auto MI = MF->CreateMachineInstr(MCID, DebugLoc());
Fix initialization-order-fiasco error in "Add a heap alloc site marker field to the ExtraInfo in MachineInstrs"
2019-10-31 18:48:52 +01:00
auto MAI = MCAsmInfo();
auto MC = createMCContext(&MAI);
Recommit "Add a heap alloc site marker field to the ExtraInfo in MachineInstrs" Summary: Fixes some things from original commit at https://reviews.llvm.org/D69136. The main change is that the heap alloc marker is always stored as ExtraInfo in the machine instruction instead of in the PointerSumType because it cannot hold more than 4 pointer types. Add instruction marker to MachineInstr ExtraInfo. This does almost the same thing as Pre/PostInstrSymbols, except that it doesn't create a label until printing instructions. This allows for labels to be put around instructions that are deleted/duplicated somewhere. Use this marker to track heap alloc site call instructions. Reviewers: rnk Subscribers: MatzeB, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69536
2019-10-28 22:53:32 +01:00
auto MMO = MF->getMachineMemOperand(MachinePointerInfo(),
[Alignment][NFC] Use Align version of getMachineMemOperand Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Subscribers: jyknight, sdardis, nemanjai, hiraditya, kbarton, fedor.sergeev, asb, rbar, johnrusso, simoncook, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, rogfer01, MartinMosbeck, brucehoult, the_o, jfb, PkmX, jocewei, Jim, lenary, s.egerton, pzheng, sameer.abuasal, apazos, luismarques, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D77059
2020-03-30 16:45:57 +02:00
MachineMemOperand::MOLoad, 8, Align(8));
Recommit "Add a heap alloc site marker field to the ExtraInfo in MachineInstrs" Summary: Fixes some things from original commit at https://reviews.llvm.org/D69136. The main change is that the heap alloc marker is always stored as ExtraInfo in the machine instruction instead of in the PointerSumType because it cannot hold more than 4 pointer types. Add instruction marker to MachineInstr ExtraInfo. This does almost the same thing as Pre/PostInstrSymbols, except that it doesn't create a label until printing instructions. This allows for labels to be put around instructions that are deleted/duplicated somewhere. Use this marker to track heap alloc site call instructions. Reviewers: rnk Subscribers: MatzeB, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69536
2019-10-28 22:53:32 +01:00
SmallVector<MachineMemOperand *, 2> MMOs;
MMOs.push_back(MMO);
MMOs.push_back(MMO);
MCSymbol *Sym1 = MC->createTempSymbol("pre_label", false);
MCSymbol *Sym2 = MC->createTempSymbol("post_label", false);
MDNode *MDN = MDNode::getDistinct(Ctx, None);
MI->setMemRefs(*MF, MMOs);
MI->setPreInstrSymbol(*MF, Sym1);
MI->setPostInstrSymbol(*MF, Sym2);
MI->setHeapAllocMarker(*MF, MDN);
MI->setPostInstrSymbol(*MF, nullptr);
ASSERT_TRUE(MI->memoperands().size() == 2);
ASSERT_TRUE(MI->getPreInstrSymbol() == Sym1);
ASSERT_FALSE(MI->getPostInstrSymbol());
ASSERT_TRUE(MI->getHeapAllocMarker() == MDN);
MI->setHeapAllocMarker(*MF, nullptr);
ASSERT_TRUE(MI->memoperands().size() == 2);
ASSERT_TRUE(MI->getPreInstrSymbol() == Sym1);
ASSERT_FALSE(MI->getPostInstrSymbol());
ASSERT_FALSE(MI->getHeapAllocMarker());
MI->setPreInstrSymbol(*MF, nullptr);
ASSERT_TRUE(MI->memoperands().size() == 2);
ASSERT_FALSE(MI->getPreInstrSymbol());
ASSERT_FALSE(MI->getPostInstrSymbol());
ASSERT_FALSE(MI->getHeapAllocMarker());
MI->setMemRefs(*MF, {});
ASSERT_TRUE(MI->memoperands_empty());
ASSERT_FALSE(MI->getPreInstrSymbol());
ASSERT_FALSE(MI->getPostInstrSymbol());
ASSERT_FALSE(MI->getHeapAllocMarker());
}
Switch from llvm::is_trivially_copyable to std::is_trivially_copyable GCC<5 did not support std::is_trivially_copyable. Now LLVM builds require 5.1 we can migrate to std::is_trivially_copyable. The Optional.h change made MSVC choke (https://buildkite.com/llvm-project/premerge-checks/builds/18587#cd1bb616-ffdc-4581-9795-b42c284196de) so I leave it out for now. Differential Revision: https://reviews.llvm.org/D92514
2020-12-03 07:02:48 +01:00
static_assert(std::is_trivially_copyable<MCOperand>::value,
"trivially copyable");
Replace llvm::isPodLike<...> by llvm::is_trivially_copyable<...> As noted in https://bugs.llvm.org/show_bug.cgi?id=36651, the specialization for isPodLike<std::pair<...>> did not match the expectation of std::is_trivially_copyable which makes the memcpy optimization invalid. This patch renames the llvm::isPodLike trait into llvm::is_trivially_copyable. Unfortunately std::is_trivially_copyable is not portable across compiler / STL versions. So a portable version is provided too. Note that the following specialization were invalid: std::pair<T0, T1> llvm::Optional<T> Tests have been added to assert that former specialization are respected by the standard usage of llvm::is_trivially_copyable, and that when a decent version of std::is_trivially_copyable is available, llvm::is_trivially_copyable is compared to std::is_trivially_copyable. As of this patch, llvm::Optional is no longer considered trivially copyable, even if T is. This is to be fixed in a later patch, as it has impact on a long-running bug (see r347004) Note that GCC warns about this UB, but this got silented by https://reviews.llvm.org/D50296. Differential Revision: https://reviews.llvm.org/D54472 llvm-svn: 351701
2019-01-20 22:19:56 +01:00
MachineInstr: Make isEqual agree with getHashValue in MachineInstrExpressionTrait MachineInstr::isIdenticalTo has a lot of logic for dealing with register Defs (i.e. deciding whether to take them into account or ignore them). This logic gets things wrong in some obscure cases, for instance if an operand is not a Def for both the current MI and the one we are comparing to. I'm not sure if it's possible for this to happen for regular register operands, but it may happen in the ARM backend for special operands which use sentinel values for the register (i.e. 0, which is neither a physical register nor a virtual one). This causes MachineInstrExpressionTrait::isEqual (which uses MachineInstr::isIdenticalTo) to return true for the following instructions, which are the same except for the fact that one sets the flags and the other one doesn't: %1114 = ADDrsi %1113, %216, 17, 14, _, def _ %1115 = ADDrsi %1113, %216, 17, 14, _, _ OTOH, MachineInstrExpressionTrait::getHashValue returns different values for the 2 instructions due to the different isDef on the last operand. In practice this means that when trying to add those instructions to a DenseMap, they will be considered different because of their different hash values, but when growing the map we might get an assertion while copying from the old buckets to the new buckets because isEqual misleadingly returns true. This patch makes sure that isEqual and getHashValue agree, by improving the checks in MachineInstr::isIdenticalTo when we are ignoring virtual register definitions (which is what the Trait uses). Firstly, instead of checking isPhysicalRegister, we use !isVirtualRegister, so that we cover both physical registers and sentinel values. Secondly, instead of checking MachineOperand::isReg, we use MachineOperand::isIdenticalTo, which checks isReg, isSubReg and isDef, which are the same values that the hash function uses to compute the hash. Note that the function is symmetric with this change, since if the current operand is not a Def, we check MachineOperand::isIdenticalTo, which returns false if the operands have different isDef's. Differential Revision: https://reviews.llvm.org/D38789 llvm-svn: 315579
2017-10-12 15:59:51 +02:00
} // end namespace
Reference in New Issue Copy Permalink