maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/lib/IR/Instruction.cpp

700 lines
24 KiB
C++
Raw Normal View History

Regularize header file comments llvm-svn: 9071
2003-10-13 11:32:08 +08:00
//===-- Instruction.cpp - Implement the Instruction class -----------------===//
Remove trailing whitespace llvm-svn: 21427
2005-04-22 07:48:37 +08:00
//
Added LLVM project notice to the top of every C++ source file. Header files will be on the way. llvm-svn: 9298
2003-10-21 03:43:21 +08:00
// The LLVM Compiler Infrastructure
//
Remove attribution from file headers, per discussion on llvmdev. llvm-svn: 45418
2007-12-30 04:36:04 +08:00
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
Remove trailing whitespace llvm-svn: 21427
2005-04-22 07:48:37 +08:00
//
Added LLVM project notice to the top of every C++ source file. Header files will be on the way. llvm-svn: 9298
2003-10-21 03:43:21 +08:00
//===----------------------------------------------------------------------===//
Initial revision llvm-svn: 2
2001-06-07 04:29:01 +08:00
//
Rename VMCore directory to IR. Aside from moving the actual files, this patch only updates the build system and the source file comments under lib/... that are relevant. I'll be updating other docs and other files in smaller subsequnet commits. While I've tried to test this, but it is entirely possible that there will still be some build system fallout. Also, note that I've not changed the library name itself: libLLVMCore.a is still the library name. I'd be interested in others' opinions about whether we should rename this as well (I think we should, just not sure what it might break) llvm-svn: 171359
2013-01-02 17:10:48 +08:00
// This file implements the Instruction class for the IR library.
Initial revision llvm-svn: 2
2001-06-07 04:29:01 +08:00
//
//===----------------------------------------------------------------------===//
Move all of the header files which are involved in modelling the LLVM IR into their new header subdirectory: include/llvm/IR. This matches the directory structure of lib, and begins to correct a long standing point of file layout clutter in LLVM. There are still more header files to move here, but I wanted to handle them in separate commits to make tracking what files make sense at each layer easier. The only really questionable files here are the target intrinsic tablegen files. But that's a battle I'd rather not fight today. I've updated both CMake and Makefile build systems (I think, and my tests think, but I may have missed something). I've also re-sorted the includes throughout the project. I'll be committing updates to Clang, DragonEgg, and Polly momentarily. llvm-svn: 171366
2013-01-02 19:36:10 +08:00
#include "llvm/IR/Instruction.h"
Sort the remaining #include lines in include/... and lib/.... I did this a long time ago with a janky python script, but now clang-format has built-in support for this. I fed clang-format every line with a #include and let it re-sort things according to the precise LLVM rules for include ordering baked into clang-format these days. I've reverted a number of files where the results of sorting includes isn't healthy. Either places where we have legacy code relying on particular include ordering (where possible, I'll fix these separately) or where we have particular formatting around #include lines that I didn't want to disturb in this patch. This patch is *entirely* mechanical. If you get merge conflicts or anything, just ignore the changes in this patch and run clang-format over your #include lines in the files. Sorry for any noise here, but it is important to keep these things stable. I was seeing an increasing number of patches with irrelevant re-ordering of #include lines because clang-format was used. This patch at least isolates that churn, makes it easy to skip when resolving conflicts, and gets us to a clean baseline (again). llvm-svn: 304787
2017-06-06 19:49:48 +08:00
#include "llvm/ADT/DenseSet.h"
[Modules] Move CallSite into the IR library where it belogs. It is abstracting between a CallInst and an InvokeInst, both of which are IR concepts. llvm-svn: 202816
2014-03-04 19:01:28 +08:00
#include "llvm/IR/CallSite.h"
Move all of the header files which are involved in modelling the LLVM IR into their new header subdirectory: include/llvm/IR. This matches the directory structure of lib, and begins to correct a long standing point of file layout clutter in LLVM. There are still more header files to move here, but I wanted to handle them in separate commits to make tracking what files make sense at each layer easier. The only really questionable files here are the target intrinsic tablegen files. But that's a battle I'd rather not fight today. I've updated both CMake and Makefile build systems (I think, and my tests think, but I may have missed something). I've also re-sorted the includes throughout the project. I'll be committing updates to Clang, DragonEgg, and Polly momentarily. llvm-svn: 171366
2013-01-02 19:36:10 +08:00
#include "llvm/IR/Constants.h"
#include "llvm/IR/Instructions.h"
Updates branch_weights annotation for call instructions during inlining. Summary: Inliner should update the branch_weights annotation to scale it to proper value. Reviewers: davidxl, eraman Reviewed By: eraman Subscribers: zzheng, llvm-commits Differential Revision: https://reviews.llvm.org/D30767 llvm-svn: 298270
2017-03-21 00:40:44 +08:00
#include "llvm/IR/MDBuilder.h"
Sort the remaining #include lines in include/... and lib/.... I did this a long time ago with a janky python script, but now clang-format has built-in support for this. I fed clang-format every line with a #include and let it re-sort things according to the precise LLVM rules for include ordering baked into clang-format these days. I've reverted a number of files where the results of sorting includes isn't healthy. Either places where we have legacy code relying on particular include ordering (where possible, I'll fix these separately) or where we have particular formatting around #include lines that I didn't want to disturb in this patch. This patch is *entirely* mechanical. If you get merge conflicts or anything, just ignore the changes in this patch and run clang-format over your #include lines in the files. Sorry for any noise here, but it is important to keep these things stable. I was seeing an increasing number of patches with irrelevant re-ordering of #include lines because clang-format was used. This patch at least isolates that churn, makes it easy to skip when resolving conflicts, and gets us to a clean baseline (again). llvm-svn: 304787
2017-06-06 19:49:48 +08:00
#include "llvm/IR/Module.h"
Move all of the header files which are involved in modelling the LLVM IR into their new header subdirectory: include/llvm/IR. This matches the directory structure of lib, and begins to correct a long standing point of file layout clutter in LLVM. There are still more header files to move here, but I wanted to handle them in separate commits to make tracking what files make sense at each layer easier. The only really questionable files here are the target intrinsic tablegen files. But that's a battle I'd rather not fight today. I've updated both CMake and Makefile build systems (I think, and my tests think, but I may have missed something). I've also re-sorted the includes throughout the project. I'll be committing updates to Clang, DragonEgg, and Polly momentarily. llvm-svn: 171366
2013-01-02 19:36:10 +08:00
#include "llvm/IR/Operator.h"
#include "llvm/IR/Type.h"
* Finegrainify namespacification * Add new constructors to allow insertion of terminator instructions at the end of basic blocks. * Move a ReturnInst method out-of-line, so that the vtable and type info don't need to be emitted to every translation unit that uses the class. llvm-svn: 10107
2003-11-21 01:45:12 +08:00
using namespace llvm;
Put all LLVM code into the llvm namespace, as per bug 109. llvm-svn: 9903
2003-11-12 06:41:34 +08:00
land David Blaikie's patch to de-constify Type, with a few tweaks. llvm-svn: 135375
2011-07-18 12:54:35 +08:00
Instruction::Instruction(Type *ty, unsigned it, Use *Ops, unsigned NumOps,
Refactor the setName stuff, moving it down the inheritance hierarchy, to solve a crash in -instcombine -debug that was hit while investigating PR1217 llvm-svn: 34544
2007-02-24 08:55:48 +08:00
Instruction *InsertBefore)
[C++11] More 'nullptr' conversion or in some cases just using a boolean check instead of comparing to nullptr. llvm-svn: 205831
2014-04-09 14:08:46 +08:00
: User(ty, Value::InstructionVal + it, Ops, NumOps), Parent(nullptr) {
Add capability to insert an instruction into a basic block immediately after it is created, as part of the ctor call. Eliminate the GenericBinaryInst class llvm-svn: 3653
2002-09-10 23:45:53 +08:00
// If requested, insert this instruction into a basic block...
if (InsertBefore) {
De-duplicate common expression, NFC. llvm-svn: 239736
2015-06-16 01:03:35 +08:00
BasicBlock *BB = InsertBefore->getParent();
assert(BB && "Instruction to insert before is not in a basic block!");
IR: Remove implicit iterator conversions from lib/IR, NFC Stop converting implicitly between iterators and pointers/references in lib/IR. For convenience, I've added a `getIterator()` accessor to `ilist_node` so that callers don't need to know how to spell the iterator class (i.e., they can use `X.getIterator()` instead of `Function::iterator(X)`). I'll eventually disallow these implicit conversions entirely, but there's a lot of code, so it doesn't make sense to do it all in one patch. One library or so at a time. Why? To root out cases of `getNextNode()` and `getPrevNode()` being used in iterator logic. The design of `ilist` makes that invalid when the current node could be at the back of the list, but it happens to "work" right now because of a bug where those functions never return `nullptr` if you're using a half-node sentinel. Before I can fix the function, I have to remove uses of it that rely on it misbehaving. (Maybe the function should just be deleted anyway? But I don't want deleting it -- potentially a huge project -- to block fixing ilist/iplist.) llvm-svn: 249782
2015-10-09 07:49:46 +08:00
BB->getInstList().insert(InsertBefore->getIterator(), this);
Add capability to insert an instruction into a basic block immediately after it is created, as part of the ctor call. Eliminate the GenericBinaryInst class llvm-svn: 3653
2002-09-10 23:45:53 +08:00
}
Initial revision llvm-svn: 2
2001-06-07 04:29:01 +08:00
}
land David Blaikie's patch to de-constify Type, with a few tweaks. llvm-svn: 135375
2011-07-18 12:54:35 +08:00
Instruction::Instruction(Type *ty, unsigned it, Use *Ops, unsigned NumOps,
Refactor the setName stuff, moving it down the inheritance hierarchy, to solve a crash in -instcombine -debug that was hit while investigating PR1217 llvm-svn: 34544
2007-02-24 08:55:48 +08:00
BasicBlock *InsertAtEnd)
[C++11] More 'nullptr' conversion or in some cases just using a boolean check instead of comparing to nullptr. llvm-svn: 205831
2014-04-09 14:08:46 +08:00
: User(ty, Value::InstructionVal + it, Ops, NumOps), Parent(nullptr) {
Refactor common initialization code in private init() functions. This is a first step in supplying append to basic block constructors for all instruction types. llvm-svn: 13793
2004-05-27 05:41:09 +08:00
// append this instruction into the basic block
assert(InsertAtEnd && "Basic block to append to may not be NULL!");
InsertAtEnd->getInstList().push_back(this);
Switch UnaryOperators to default to passing names up by const char* when possible. This speeds up bcreading by 1.5%. llvm-svn: 34233
2007-02-13 15:54:42 +08:00
}
Reverting dtor devirtualization patch. _sabre_: it has a major problem: by the time ~Value is run, all of the "parts" of the derived classes have been destroyed _sabre_: the vtable lives to fight another day llvm-svn: 44760
2007-12-10 10:14:30 +08:00
Instruction::~Instruction() {
[C++11] More 'nullptr' conversion. In some cases just using a boolean check instead of comparing to nullptr. llvm-svn: 206252
2014-04-15 14:32:26 +08:00
assert(!Parent && "Instruction still linked in the program!");
Rename removeAllMetadata to clearMetadataHashEntries and simplify it to just do the things that need to be done when an instruction is deleted. llvm-svn: 108948
2010-07-21 06:25:04 +08:00
if (hasMetadataHashEntry())
clearMetadataHashEntries();
Add some out-of-line virtual dtors so that the class has a "home", preventing vtables for (e.g.) Instruction from being emitted into every .o file. llvm-svn: 28898
2006-06-22 00:53:47 +08:00
}
Move code out of header files into .cpp files to make future changes easier llvm-svn: 3605
2002-09-07 05:33:15 +08:00
void Instruction::setParent(BasicBlock *P) {
Parent = P;
}
Remove getDataLayout() from Instruction/GlobalValue/BasicBlock/Function Summary: This does not conceptually belongs here. Instead provide a shortcut getModule() that provides access to the DataLayout. Reviewers: chandlerc, echristo Reviewed By: echristo Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D8027 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 231147
2015-03-04 06:01:13 +08:00
const Module *Instruction::getModule() const {
return getParent()->getModule();
}
Add Instruction::getFunction; NFC Will be used in a upcoming patch. llvm-svn: 254975
2015-12-08 08:13:12 +08:00
const Function *Instruction::getFunction() const {
return getParent()->getParent();
}
[PlaceSafepoints] Cleanup InsertSafepointPoll function While working on another change, I noticed that the naming in this function was mildly deceptive. While fixing that, I took the oppurtunity to modernize some of the code. NFC intended. llvm-svn: 238252
2015-05-27 05:03:23 +08:00
Implement remove/eraseFromParent methods llvm-svn: 16922
2004-10-12 06:21:39 +08:00
void Instruction::removeFromParent() {
IR: Remove implicit iterator conversions from lib/IR, NFC Stop converting implicitly between iterators and pointers/references in lib/IR. For convenience, I've added a `getIterator()` accessor to `ilist_node` so that callers don't need to know how to spell the iterator class (i.e., they can use `X.getIterator()` instead of `Function::iterator(X)`). I'll eventually disallow these implicit conversions entirely, but there's a lot of code, so it doesn't make sense to do it all in one patch. One library or so at a time. Why? To root out cases of `getNextNode()` and `getPrevNode()` being used in iterator logic. The design of `ilist` makes that invalid when the current node could be at the back of the list, but it happens to "work" right now because of a bug where those functions never return `nullptr` if you're using a half-node sentinel. Before I can fix the function, I have to remove uses of it that rely on it misbehaving. (Maybe the function should just be deleted anyway? But I don't want deleting it -- potentially a huge project -- to block fixing ilist/iplist.) llvm-svn: 249782
2015-10-09 07:49:46 +08:00
getParent()->getInstList().remove(getIterator());
Implement remove/eraseFromParent methods llvm-svn: 16922
2004-10-12 06:21:39 +08:00
}
Return iterator from Instruction::eraseFromParent. Summary: This is necessary in order to make removal while using reverse iterators work. (See http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-March/084122.html) Updates to other eraseFromParent's to come in later patches. Reviewers: chandlerc Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D8783 llvm-svn: 233869
2015-04-02 08:03:07 +08:00
iplist<Instruction>::iterator Instruction::eraseFromParent() {
IR: Remove implicit iterator conversions from lib/IR, NFC Stop converting implicitly between iterators and pointers/references in lib/IR. For convenience, I've added a `getIterator()` accessor to `ilist_node` so that callers don't need to know how to spell the iterator class (i.e., they can use `X.getIterator()` instead of `Function::iterator(X)`). I'll eventually disallow these implicit conversions entirely, but there's a lot of code, so it doesn't make sense to do it all in one patch. One library or so at a time. Why? To root out cases of `getNextNode()` and `getPrevNode()` being used in iterator logic. The design of `ilist` makes that invalid when the current node could be at the back of the list, but it happens to "work" right now because of a bug where those functions never return `nullptr` if you're using a half-node sentinel. Before I can fix the function, I have to remove uses of it that rely on it misbehaving. (Maybe the function should just be deleted anyway? But I don't want deleting it -- potentially a huge project -- to block fixing ilist/iplist.) llvm-svn: 249782
2015-10-09 07:49:46 +08:00
return getParent()->getInstList().erase(getIterator());
Implement remove/eraseFromParent methods llvm-svn: 16922
2004-10-12 06:21:39 +08:00
}
Create a static version of Instruction::getOpcodeName(opCode) that can be invoked with only an opcode (i.e., without an instruction). Move all opCode->opCodeName translations there. llvm-svn: 2900
2002-07-15 07:09:40 +08:00
fix typos; NFC llvm-svn: 256881
2016-01-06 08:18:29 +08:00
/// Insert an unlinked instruction into a basic block immediately before the
/// specified instruction.
Add an insertBefore method for attaching previously unattached instructions, such as those created by clone(), to a basic block. llvm-svn: 52424
2008-06-18 02:29:27 +08:00
void Instruction::insertBefore(Instruction *InsertPos) {
IR: Remove implicit iterator conversions from lib/IR, NFC Stop converting implicitly between iterators and pointers/references in lib/IR. For convenience, I've added a `getIterator()` accessor to `ilist_node` so that callers don't need to know how to spell the iterator class (i.e., they can use `X.getIterator()` instead of `Function::iterator(X)`). I'll eventually disallow these implicit conversions entirely, but there's a lot of code, so it doesn't make sense to do it all in one patch. One library or so at a time. Why? To root out cases of `getNextNode()` and `getPrevNode()` being used in iterator logic. The design of `ilist` makes that invalid when the current node could be at the back of the list, but it happens to "work" right now because of a bug where those functions never return `nullptr` if you're using a half-node sentinel. Before I can fix the function, I have to remove uses of it that rely on it misbehaving. (Maybe the function should just be deleted anyway? But I don't want deleting it -- potentially a huge project -- to block fixing ilist/iplist.) llvm-svn: 249782
2015-10-09 07:49:46 +08:00
InsertPos->getParent()->getInstList().insert(InsertPos->getIterator(), this);
Add an insertBefore method for attaching previously unattached instructions, such as those created by clone(), to a basic block. llvm-svn: 52424
2008-06-18 02:29:27 +08:00
}
fix typos; NFC llvm-svn: 256881
2016-01-06 08:18:29 +08:00
/// Insert an unlinked instruction into a basic block immediately after the
/// specified instruction.
add a new insertAfter method, patch by Tom Jablin! llvm-svn: 62158
2009-01-13 15:43:51 +08:00
void Instruction::insertAfter(Instruction *InsertPos) {
IR: Remove implicit iterator conversions from lib/IR, NFC Stop converting implicitly between iterators and pointers/references in lib/IR. For convenience, I've added a `getIterator()` accessor to `ilist_node` so that callers don't need to know how to spell the iterator class (i.e., they can use `X.getIterator()` instead of `Function::iterator(X)`). I'll eventually disallow these implicit conversions entirely, but there's a lot of code, so it doesn't make sense to do it all in one patch. One library or so at a time. Why? To root out cases of `getNextNode()` and `getPrevNode()` being used in iterator logic. The design of `ilist` makes that invalid when the current node could be at the back of the list, but it happens to "work" right now because of a bug where those functions never return `nullptr` if you're using a half-node sentinel. Before I can fix the function, I have to remove uses of it that rely on it misbehaving. (Maybe the function should just be deleted anyway? But I don't want deleting it -- potentially a huge project -- to block fixing ilist/iplist.) llvm-svn: 249782
2015-10-09 07:49:46 +08:00
InsertPos->getParent()->getInstList().insertAfter(InsertPos->getIterator(),
this);
add a new insertAfter method, patch by Tom Jablin! llvm-svn: 62158
2009-01-13 15:43:51 +08:00
}
fix typos; NFC llvm-svn: 256881
2016-01-06 08:18:29 +08:00
/// Unlink this instruction from its current basic block and insert it into the
/// basic block that MovePos lives in, right before MovePos.
add new helper function llvm-svn: 22698
2005-08-08 13:21:50 +08:00
void Instruction::moveBefore(Instruction *MovePos) {
Scalar: Avoid dereferencing end() in IndVarSimplify IndVarSimplify::sinkUnusedInvariants calls BasicBlock::getFirstInsertionPt on the ExitBlock and moves instructions before it. This can return end(), so it's not safe to dereference. Add an iterator-based overload to Instruction::moveBefore to avoid the UB. llvm-svn: 278886
2016-08-17 09:54:41 +08:00
moveBefore(*MovePos->getParent(), MovePos->getIterator());
}
[Instruction] add moveAfter() convenience function; NFCI As suggested in D37121, here's a wrapper for removeFromParent() + insertAfter(), but implemented using moveBefore() for symmetry/efficiency. Differential Revision: https://reviews.llvm.org/D37239 llvm-svn: 312001
2017-08-29 22:07:48 +08:00
void Instruction::moveAfter(Instruction *MovePos) {
moveBefore(*MovePos->getParent(), ++MovePos->getIterator());
}
Scalar: Avoid dereferencing end() in IndVarSimplify IndVarSimplify::sinkUnusedInvariants calls BasicBlock::getFirstInsertionPt on the ExitBlock and moves instructions before it. This can return end(), so it's not safe to dereference. Add an iterator-based overload to Instruction::moveBefore to avoid the UB. llvm-svn: 278886
2016-08-17 09:54:41 +08:00
void Instruction::moveBefore(BasicBlock &BB,
SymbolTableList<Instruction>::iterator I) {
assert(I == BB.end() || I->getParent() == &BB);
BB.getInstList().splice(I, getParent()->getInstList(), getIterator());
add new helper function llvm-svn: 22698
2005-08-08 13:21:50 +08:00
}
[EarlyCSE] Take the intersection of flags on instructions EarlyCSE had inconsistent behavior with regards to flag'd instructions: - In some cases, it would pessimize if the available instruction had different flags by not performing CSE. - In other cases, it would miscompile if it replaced an instruction which had no flags with an instruction which has flags. Fix this by being more consistent with our flag handling by utilizing andIRFlags. llvm-svn: 267111
2016-04-22 14:37:45 +08:00
void Instruction::setHasNoUnsignedWrap(bool b) {
cast<OverflowingBinaryOperator>(this)->setHasNoUnsignedWrap(b);
}
void Instruction::setHasNoSignedWrap(bool b) {
cast<OverflowingBinaryOperator>(this)->setHasNoSignedWrap(b);
}
void Instruction::setIsExact(bool b) {
cast<PossiblyExactOperator>(this)->setIsExact(b);
}
bool Instruction::hasNoUnsignedWrap() const {
return cast<OverflowingBinaryOperator>(this)->hasNoUnsignedWrap();
}
bool Instruction::hasNoSignedWrap() const {
return cast<OverflowingBinaryOperator>(this)->hasNoSignedWrap();
}
[IR] Add a Instruction::dropPoisonGeneratingFlags helper Summary: The helper will be used in a later change. This change itself is NFC since the only user of this new function is its unit test. Reviewers: majnemer, efriedma Reviewed By: efriedma Subscribers: efriedma, mcrosier, llvm-commits Differential Revision: https://reviews.llvm.org/D30184 llvm-svn: 296035
2017-02-24 06:50:52 +08:00
void Instruction::dropPoisonGeneratingFlags() {
switch (getOpcode()) {
case Instruction::Add:
case Instruction::Sub:
case Instruction::Mul:
case Instruction::Shl:
cast<OverflowingBinaryOperator>(this)->setHasNoUnsignedWrap(false);
cast<OverflowingBinaryOperator>(this)->setHasNoSignedWrap(false);
break;
case Instruction::UDiv:
case Instruction::SDiv:
case Instruction::AShr:
case Instruction::LShr:
cast<PossiblyExactOperator>(this)->setIsExact(false);
break;
case Instruction::GetElementPtr:
cast<GetElementPtrInst>(this)->setIsInBounds(false);
break;
}
}
[EarlyCSE] Take the intersection of flags on instructions EarlyCSE had inconsistent behavior with regards to flag'd instructions: - In some cases, it would pessimize if the available instruction had different flags by not performing CSE. - In other cases, it would miscompile if it replaced an instruction which had no flags with an instruction which has flags. Fix this by being more consistent with our flag handling by utilizing andIRFlags. llvm-svn: 267111
2016-04-22 14:37:45 +08:00
bool Instruction::isExact() const {
return cast<PossiblyExactOperator>(this)->isExact();
}
Fast-math interfaces for Instructions Add in getter/setter methods for Instructions, allowing them to be the interface to FPMathOperator similarly to now NUS/NSW is handled. llvm-svn: 168642
2012-11-27 08:41:22 +08:00
void Instruction::setHasUnsafeAlgebra(bool B) {
assert(isa<FPMathOperator>(this) && "setting fast-math flag on invalid op");
cast<FPMathOperator>(this)->setHasUnsafeAlgebra(B);
}
void Instruction::setHasNoNaNs(bool B) {
assert(isa<FPMathOperator>(this) && "setting fast-math flag on invalid op");
cast<FPMathOperator>(this)->setHasNoNaNs(B);
}
void Instruction::setHasNoInfs(bool B) {
assert(isa<FPMathOperator>(this) && "setting fast-math flag on invalid op");
cast<FPMathOperator>(this)->setHasNoInfs(B);
}
void Instruction::setHasNoSignedZeros(bool B) {
assert(isa<FPMathOperator>(this) && "setting fast-math flag on invalid op");
cast<FPMathOperator>(this)->setHasNoSignedZeros(B);
}
void Instruction::setHasAllowReciprocal(bool B) {
assert(isa<FPMathOperator>(this) && "setting fast-math flag on invalid op");
cast<FPMathOperator>(this)->setHasAllowReciprocal(B);
}
void Instruction::setFastMathFlags(FastMathFlags FMF) {
assert(isa<FPMathOperator>(this) && "setting fast-math flag on invalid op");
cast<FPMathOperator>(this)->setFastMathFlags(FMF);
}
Fix a logic bug when copying fast-math flags. "Setting" does not equal "copying". This bug has sat dormant for 2 reasons: 1. The unit test was not adequate. 2. Every current user of the "copyFastMathFlags" API is operating on a new instruction. (ie, all existing fast-math flags are off). If you copy flags to an existing instruction that has some flags on already, you will not necessarily turn them off as expected. I uncovered this bug while trying to implement a fix for PR20802. llvm-svn: 216939
2014-09-03 04:03:00 +08:00
void Instruction::copyFastMathFlags(FastMathFlags FMF) {
assert(isa<FPMathOperator>(this) && "copying fast-math flag on invalid op");
cast<FPMathOperator>(this)->copyFastMathFlags(FMF);
}
Fast-math interfaces for Instructions Add in getter/setter methods for Instructions, allowing them to be the interface to FPMathOperator similarly to now NUS/NSW is handled. llvm-svn: 168642
2012-11-27 08:41:22 +08:00
bool Instruction::hasUnsafeAlgebra() const {
Fix assert comments in Instruction.cpp. llvm-svn: 210684
2014-06-12 02:26:29 +08:00
assert(isa<FPMathOperator>(this) && "getting fast-math flag on invalid op");
Fast-math interfaces for Instructions Add in getter/setter methods for Instructions, allowing them to be the interface to FPMathOperator similarly to now NUS/NSW is handled. llvm-svn: 168642
2012-11-27 08:41:22 +08:00
return cast<FPMathOperator>(this)->hasUnsafeAlgebra();
}
bool Instruction::hasNoNaNs() const {
Fix assert comments in Instruction.cpp. llvm-svn: 210684
2014-06-12 02:26:29 +08:00
assert(isa<FPMathOperator>(this) && "getting fast-math flag on invalid op");
Fast-math interfaces for Instructions Add in getter/setter methods for Instructions, allowing them to be the interface to FPMathOperator similarly to now NUS/NSW is handled. llvm-svn: 168642
2012-11-27 08:41:22 +08:00
return cast<FPMathOperator>(this)->hasNoNaNs();
}
bool Instruction::hasNoInfs() const {
Fix assert comments in Instruction.cpp. llvm-svn: 210684
2014-06-12 02:26:29 +08:00
assert(isa<FPMathOperator>(this) && "getting fast-math flag on invalid op");
Fast-math interfaces for Instructions Add in getter/setter methods for Instructions, allowing them to be the interface to FPMathOperator similarly to now NUS/NSW is handled. llvm-svn: 168642
2012-11-27 08:41:22 +08:00
return cast<FPMathOperator>(this)->hasNoInfs();
}
bool Instruction::hasNoSignedZeros() const {
Fix assert comments in Instruction.cpp. llvm-svn: 210684
2014-06-12 02:26:29 +08:00
assert(isa<FPMathOperator>(this) && "getting fast-math flag on invalid op");
Fast-math interfaces for Instructions Add in getter/setter methods for Instructions, allowing them to be the interface to FPMathOperator similarly to now NUS/NSW is handled. llvm-svn: 168642
2012-11-27 08:41:22 +08:00
return cast<FPMathOperator>(this)->hasNoSignedZeros();
}
bool Instruction::hasAllowReciprocal() const {
Fix assert comments in Instruction.cpp. llvm-svn: 210684
2014-06-12 02:26:29 +08:00
assert(isa<FPMathOperator>(this) && "getting fast-math flag on invalid op");
Fast-math interfaces for Instructions Add in getter/setter methods for Instructions, allowing them to be the interface to FPMathOperator similarly to now NUS/NSW is handled. llvm-svn: 168642
2012-11-27 08:41:22 +08:00
return cast<FPMathOperator>(this)->hasAllowReciprocal();
}
[IR] Add AllowContract to FastMathFlags -ffp-contract=fast does not currently work with LTO because it's passed as a TargetOption to the backend rather than in the IR. This adds it to FastMathFlags. This is toward fixing PR25721 Differential Revision: https://reviews.llvm.org/D31164 llvm-svn: 298939
2017-03-29 04:11:52 +08:00
bool Instruction::hasAllowContract() const {
assert(isa<FPMathOperator>(this) && "getting fast-math flag on invalid op");
return cast<FPMathOperator>(this)->hasAllowContract();
}
Fast-math interfaces for Instructions Add in getter/setter methods for Instructions, allowing them to be the interface to FPMathOperator similarly to now NUS/NSW is handled. llvm-svn: 168642
2012-11-27 08:41:22 +08:00
FastMathFlags Instruction::getFastMathFlags() const {
Fix assert comments in Instruction.cpp. llvm-svn: 210684
2014-06-12 02:26:29 +08:00
assert(isa<FPMathOperator>(this) && "getting fast-math flag on invalid op");
Fast-math interfaces for Instructions Add in getter/setter methods for Instructions, allowing them to be the interface to FPMathOperator similarly to now NUS/NSW is handled. llvm-svn: 168642
2012-11-27 08:41:22 +08:00
return cast<FPMathOperator>(this)->getFastMathFlags();
}
add new helper function llvm-svn: 22698
2005-08-08 13:21:50 +08:00
copyFastMathFlags utility and test case llvm-svn: 168943
2012-11-30 05:25:12 +08:00
void Instruction::copyFastMathFlags(const Instruction *I) {
Fix a logic bug when copying fast-math flags. "Setting" does not equal "copying". This bug has sat dormant for 2 reasons: 1. The unit test was not adequate. 2. Every current user of the "copyFastMathFlags" API is operating on a new instruction. (ie, all existing fast-math flags are off). If you copy flags to an existing instruction that has some flags on already, you will not necessarily turn them off as expected. I uncovered this bug while trying to implement a fix for PR20802. llvm-svn: 216939
2014-09-03 04:03:00 +08:00
copyFastMathFlags(I->getFastMathFlags());
copyFastMathFlags utility and test case llvm-svn: 168943
2012-11-30 05:25:12 +08:00
}
[LoopVectorize] Don't preserve nsw/nuw flags on shrunken ops. If we're shrinking a binary operation, it may be the case that the new operations wraps where the old didn't. If this happens, the behavior should be well-defined. So, we can't always carry wrapping flags with us when we shrink operations. If we do, we get incorrect optimizations in cases like: void foo(const unsigned char *from, unsigned char *to, int n) { for (int i = 0; i < n; i++) to[i] = from[i] - 128; } which gets optimized to: void foo(const unsigned char *from, unsigned char *to, int n) { for (int i = 0; i < n; i++) to[i] = from[i] | 128; } Because: - InstCombine turned `sub i32 %from.i, 128` into `add nuw nsw i32 %from.i, 128`. - LoopVectorize vectorized the add to be `add nuw nsw <16 x i8>` with a vector full of `i8 128`s - InstCombine took advantage of the fact that the newly-shrunken add "couldn't wrap", and changed the `add` to an `or`. InstCombine seems happy to figure out whether we can add nuw/nsw on its own, so I just decided to drop the flags. There are already a number of places in LoopVectorize where we rely on InstCombine to clean up. llvm-svn: 305053
2017-06-09 11:56:15 +08:00
void Instruction::copyIRFlags(const Value *V, bool IncludeWrapFlags) {
[EarlyCSE] Take the intersection of flags on instructions EarlyCSE had inconsistent behavior with regards to flag'd instructions: - In some cases, it would pessimize if the available instruction had different flags by not performing CSE. - In other cases, it would miscompile if it replaced an instruction which had no flags with an instruction which has flags. Fix this by being more consistent with our flag handling by utilizing andIRFlags. llvm-svn: 267111
2016-04-22 14:37:45 +08:00
// Copy the wrapping flags.
[LoopVectorize] Don't preserve nsw/nuw flags on shrunken ops. If we're shrinking a binary operation, it may be the case that the new operations wraps where the old didn't. If this happens, the behavior should be well-defined. So, we can't always carry wrapping flags with us when we shrink operations. If we do, we get incorrect optimizations in cases like: void foo(const unsigned char *from, unsigned char *to, int n) { for (int i = 0; i < n; i++) to[i] = from[i] - 128; } which gets optimized to: void foo(const unsigned char *from, unsigned char *to, int n) { for (int i = 0; i < n; i++) to[i] = from[i] | 128; } Because: - InstCombine turned `sub i32 %from.i, 128` into `add nuw nsw i32 %from.i, 128`. - LoopVectorize vectorized the add to be `add nuw nsw <16 x i8>` with a vector full of `i8 128`s - InstCombine took advantage of the fact that the newly-shrunken add "couldn't wrap", and changed the `add` to an `or`. InstCombine seems happy to figure out whether we can add nuw/nsw on its own, so I just decided to drop the flags. There are already a number of places in LoopVectorize where we rely on InstCombine to clean up. llvm-svn: 305053
2017-06-09 11:56:15 +08:00
if (IncludeWrapFlags && isa<OverflowingBinaryOperator>(this)) {
if (auto *OB = dyn_cast<OverflowingBinaryOperator>(V)) {
[GVN] Respect fast-math-flags on fcmps We assumed that flags were only present on binary operators. This is not true, they may also be present on calls and fcmps. llvm-svn: 267113
2016-04-22 14:37:51 +08:00
setHasNoSignedWrap(OB->hasNoSignedWrap());
setHasNoUnsignedWrap(OB->hasNoUnsignedWrap());
}
[EarlyCSE] Take the intersection of flags on instructions EarlyCSE had inconsistent behavior with regards to flag'd instructions: - In some cases, it would pessimize if the available instruction had different flags by not performing CSE. - In other cases, it would miscompile if it replaced an instruction which had no flags with an instruction which has flags. Fix this by being more consistent with our flag handling by utilizing andIRFlags. llvm-svn: 267111
2016-04-22 14:37:45 +08:00
}
// Copy the exact flag.
if (auto *PE = dyn_cast<PossiblyExactOperator>(V))
[GVN] Respect fast-math-flags on fcmps We assumed that flags were only present on binary operators. This is not true, they may also be present on calls and fcmps. llvm-svn: 267113
2016-04-22 14:37:51 +08:00
if (isa<PossiblyExactOperator>(this))
setIsExact(PE->isExact());
[EarlyCSE] Take the intersection of flags on instructions EarlyCSE had inconsistent behavior with regards to flag'd instructions: - In some cases, it would pessimize if the available instruction had different flags by not performing CSE. - In other cases, it would miscompile if it replaced an instruction which had no flags with an instruction which has flags. Fix this by being more consistent with our flag handling by utilizing andIRFlags. llvm-svn: 267111
2016-04-22 14:37:45 +08:00
// Copy the fast-math flags.
if (auto *FP = dyn_cast<FPMathOperator>(V))
[GVN] Respect fast-math-flags on fcmps We assumed that flags were only present on binary operators. This is not true, they may also be present on calls and fcmps. llvm-svn: 267113
2016-04-22 14:37:51 +08:00
if (isa<FPMathOperator>(this))
copyFastMathFlags(FP->getFastMathFlags());
[IR] andIRFlags and copyIRFlags needs to handle GEP We didn't consider the inbounds flag on GEPs leading to downstream users introducing UB. This fixes PR28562. llvm-svn: 275532
2016-07-15 13:02:31 +08:00
if (auto *SrcGEP = dyn_cast<GetElementPtrInst>(V))
if (auto *DestGEP = dyn_cast<GetElementPtrInst>(this))
DestGEP->setIsInBounds(SrcGEP->isInBounds() | DestGEP->isInBounds());
[EarlyCSE] Take the intersection of flags on instructions EarlyCSE had inconsistent behavior with regards to flag'd instructions: - In some cases, it would pessimize if the available instruction had different flags by not performing CSE. - In other cases, it would miscompile if it replaced an instruction which had no flags with an instruction which has flags. Fix this by being more consistent with our flag handling by utilizing andIRFlags. llvm-svn: 267111
2016-04-22 14:37:45 +08:00
}
void Instruction::andIRFlags(const Value *V) {
if (auto *OB = dyn_cast<OverflowingBinaryOperator>(V)) {
[GVN] Respect fast-math-flags on fcmps We assumed that flags were only present on binary operators. This is not true, they may also be present on calls and fcmps. llvm-svn: 267113
2016-04-22 14:37:51 +08:00
if (isa<OverflowingBinaryOperator>(this)) {
setHasNoSignedWrap(hasNoSignedWrap() & OB->hasNoSignedWrap());
setHasNoUnsignedWrap(hasNoUnsignedWrap() & OB->hasNoUnsignedWrap());
}
[EarlyCSE] Take the intersection of flags on instructions EarlyCSE had inconsistent behavior with regards to flag'd instructions: - In some cases, it would pessimize if the available instruction had different flags by not performing CSE. - In other cases, it would miscompile if it replaced an instruction which had no flags with an instruction which has flags. Fix this by being more consistent with our flag handling by utilizing andIRFlags. llvm-svn: 267111
2016-04-22 14:37:45 +08:00
}
if (auto *PE = dyn_cast<PossiblyExactOperator>(V))
[GVN] Respect fast-math-flags on fcmps We assumed that flags were only present on binary operators. This is not true, they may also be present on calls and fcmps. llvm-svn: 267113
2016-04-22 14:37:51 +08:00
if (isa<PossiblyExactOperator>(this))
setIsExact(isExact() & PE->isExact());
[EarlyCSE] Take the intersection of flags on instructions EarlyCSE had inconsistent behavior with regards to flag'd instructions: - In some cases, it would pessimize if the available instruction had different flags by not performing CSE. - In other cases, it would miscompile if it replaced an instruction which had no flags with an instruction which has flags. Fix this by being more consistent with our flag handling by utilizing andIRFlags. llvm-svn: 267111
2016-04-22 14:37:45 +08:00
if (auto *FP = dyn_cast<FPMathOperator>(V)) {
[GVN] Respect fast-math-flags on fcmps We assumed that flags were only present on binary operators. This is not true, they may also be present on calls and fcmps. llvm-svn: 267113
2016-04-22 14:37:51 +08:00
if (isa<FPMathOperator>(this)) {
FastMathFlags FM = getFastMathFlags();
FM &= FP->getFastMathFlags();
copyFastMathFlags(FM);
}
[EarlyCSE] Take the intersection of flags on instructions EarlyCSE had inconsistent behavior with regards to flag'd instructions: - In some cases, it would pessimize if the available instruction had different flags by not performing CSE. - In other cases, it would miscompile if it replaced an instruction which had no flags with an instruction which has flags. Fix this by being more consistent with our flag handling by utilizing andIRFlags. llvm-svn: 267111
2016-04-22 14:37:45 +08:00
}
[IR] andIRFlags and copyIRFlags needs to handle GEP We didn't consider the inbounds flag on GEPs leading to downstream users introducing UB. This fixes PR28562. llvm-svn: 275532
2016-07-15 13:02:31 +08:00
if (auto *SrcGEP = dyn_cast<GetElementPtrInst>(V))
if (auto *DestGEP = dyn_cast<GetElementPtrInst>(this))
DestGEP->setIsInBounds(SrcGEP->isInBounds() & DestGEP->isInBounds());
[EarlyCSE] Take the intersection of flags on instructions EarlyCSE had inconsistent behavior with regards to flag'd instructions: - In some cases, it would pessimize if the available instruction had different flags by not performing CSE. - In other cases, it would miscompile if it replaced an instruction which had no flags with an instruction which has flags. Fix this by being more consistent with our flag handling by utilizing andIRFlags. llvm-svn: 267111
2016-04-22 14:37:45 +08:00
}
copyFastMathFlags utility and test case llvm-svn: 168943
2012-11-30 05:25:12 +08:00
Create a static version of Instruction::getOpcodeName(opCode) that can be invoked with only an opcode (i.e., without an instruction). Move all opCode->opCodeName translations there. llvm-svn: 2900
2002-07-15 07:09:40 +08:00
const char *Instruction::getOpcodeName(unsigned OpCode) {
switch (OpCode) {
// Terminators
Remove support for NOT instruction llvm-svn: 3323
2002-08-15 02:18:02 +08:00
case Ret: return "ret";
case Br: return "br";
Create a static version of Instruction::getOpcodeName(opCode) that can be invoked with only an opcode (i.e., without an instruction). Move all opCode->opCodeName translations there. llvm-svn: 2900
2002-07-15 07:09:40 +08:00
case Switch: return "switch";
rename indbr -> indirectbr to appease the residents of #llvm. llvm-svn: 85351
2009-10-28 08:19:10 +08:00
case IndirectBr: return "indirectbr";
Create a static version of Instruction::getOpcodeName(opCode) that can be invoked with only an opcode (i.e., without an instruction). Move all opCode->opCodeName translations there. llvm-svn: 2900
2002-07-15 07:09:40 +08:00
case Invoke: return "invoke";
Add the 'resume' instruction for the new EH rewrite. This adds the 'resume' instruction class, IR parsing, and bitcode reading and writing. The 'resume' instruction resumes propagation of an existing (in-flight) exception whose unwinding was interrupted with a 'landingpad' instruction (to be added later). llvm-svn: 136589
2011-07-31 14:30:59 +08:00
case Resume: return "resume";
Add support for undef and unreachable llvm-svn: 17041
2004-10-17 02:08:06 +08:00
case Unreachable: return "unreachable";
New EH representation for MSVC compatibility This introduces new instructions neccessary to implement MSVC-compatible exception handling support. Most of the middle-end and none of the back-end haven't been audited or updated to take them into account. Differential Revision: http://reviews.llvm.org/D11097 llvm-svn: 243766
2015-08-01 01:58:14 +08:00
case CleanupRet: return "cleanupret";
case CatchRet: return "catchret";
case CatchPad: return "catchpad";
[IR] Reformulate LLVM's EH funclet IR While we have successfully implemented a funclet-oriented EH scheme on top of LLVM IR, our scheme has some notable deficiencies: - catchendpad and cleanupendpad are necessary in the current design but they are difficult to explain to others, even to seasoned LLVM experts. - catchendpad and cleanupendpad are optimization barriers. They cannot be split and force all potentially throwing call-sites to be invokes. This has a noticable effect on the quality of our code generation. - catchpad, while similar in some aspects to invoke, is fairly awkward. It is unsplittable, starts a funclet, and has control flow to other funclets. - The nesting relationship between funclets is currently a property of control flow edges. Because of this, we are forced to carefully analyze the flow graph to see if there might potentially exist illegal nesting among funclets. While we have logic to clone funclets when they are illegally nested, it would be nicer if we had a representation which forbade them upfront. Let's clean this up a bit by doing the following: - Instead, make catchpad more like cleanuppad and landingpad: no control flow, just a bunch of simple operands; catchpad would be splittable. - Introduce catchswitch, a control flow instruction designed to model the constraints of funclet oriented EH. - Make funclet scoping explicit by having funclet instructions consume the token produced by the funclet which contains them. - Remove catchendpad and cleanupendpad. Their presence can be inferred implicitly using coloring information. N.B. The state numbering code for the CLR has been updated but the veracity of it's output cannot be spoken for. An expert should take a look to make sure the results are reasonable. Reviewers: rnk, JosephTremoulet, andrew.w.kaylor Differential Revision: http://reviews.llvm.org/D15139 llvm-svn: 255422
2015-12-12 13:38:55 +08:00
case CatchSwitch: return "catchswitch";
Remove trailing whitespace llvm-svn: 21427
2005-04-22 07:48:37 +08:00
Create a static version of Instruction::getOpcodeName(opCode) that can be invoked with only an opcode (i.e., without an instruction). Move all opCode->opCodeName translations there. llvm-svn: 2900
2002-07-15 07:09:40 +08:00
// Standard binary operators...
case Add: return "add";
Split the Add, Sub, and Mul instruction opcodes into separate integer and floating-point opcodes, introducing FAdd, FSub, and FMul. For now, the AsmParser, BitcodeReader, and IRBuilder all preserve backwards compatability, and the Core LLVM APIs preserve backwards compatibility for IR producers. Most front-ends won't need to change immediately. This implements the first step of the plan outlined here: http://nondot.org/sabre/LLVMNotes/IntegerOverflow.txt llvm-svn: 72897
2009-06-05 06:49:04 +08:00
case FAdd: return "fadd";
Create a static version of Instruction::getOpcodeName(opCode) that can be invoked with only an opcode (i.e., without an instruction). Move all opCode->opCodeName translations there. llvm-svn: 2900
2002-07-15 07:09:40 +08:00
case Sub: return "sub";
Split the Add, Sub, and Mul instruction opcodes into separate integer and floating-point opcodes, introducing FAdd, FSub, and FMul. For now, the AsmParser, BitcodeReader, and IRBuilder all preserve backwards compatability, and the Core LLVM APIs preserve backwards compatibility for IR producers. Most front-ends won't need to change immediately. This implements the first step of the plan outlined here: http://nondot.org/sabre/LLVMNotes/IntegerOverflow.txt llvm-svn: 72897
2009-06-05 06:49:04 +08:00
case FSub: return "fsub";
Create a static version of Instruction::getOpcodeName(opCode) that can be invoked with only an opcode (i.e., without an instruction). Move all opCode->opCodeName translations there. llvm-svn: 2900
2002-07-15 07:09:40 +08:00
case Mul: return "mul";
Split the Add, Sub, and Mul instruction opcodes into separate integer and floating-point opcodes, introducing FAdd, FSub, and FMul. For now, the AsmParser, BitcodeReader, and IRBuilder all preserve backwards compatability, and the Core LLVM APIs preserve backwards compatibility for IR producers. Most front-ends won't need to change immediately. This implements the first step of the plan outlined here: http://nondot.org/sabre/LLVMNotes/IntegerOverflow.txt llvm-svn: 72897
2009-06-05 06:49:04 +08:00
case FMul: return "fmul";
For PR950: Make necessary changes to support DIV -> [SUF]Div. This changes llvm to have three division instructions: signed, unsigned, floating point. The bytecode and assembler are bacwards compatible, however. llvm-svn: 31195
2006-10-26 14:15:43 +08:00
case UDiv: return "udiv";
case SDiv: return "sdiv";
case FDiv: return "fdiv";
For PR950: Replace the REM instruction with UREM, SREM and FREM. llvm-svn: 31369
2006-11-02 09:53:59 +08:00
case URem: return "urem";
case SRem: return "srem";
case FRem: return "frem";
Create a static version of Instruction::getOpcodeName(opCode) that can be invoked with only an opcode (i.e., without an instruction). Move all opCode->opCodeName translations there. llvm-svn: 2900
2002-07-15 07:09:40 +08:00
// Logical operators...
case And: return "and";
case Or : return "or";
case Xor: return "xor";
// Memory instructions...
case Alloca: return "alloca";
case Load: return "load";
case Store: return "store";
LangRef and basic memory-representation/reading/writing for 'cmpxchg' and 'atomicrmw' instructions, which allow representing all the current atomic rmw intrinsics. The allowed operands for these instructions are heavily restricted at the moment; we can probably loosen it a bit, but supporting general first-class types (where it makes sense) might get a bit complicated, given how SelectionDAG works. As an initial cut, these operations do not support specifying an alignment, but it would be possible to add if we think it's useful. Specifying an alignment lower than the natural alignment would be essentially impossible to support on anything other than x86, but specifying a greater alignment would be possible. I can't think of any useful optimizations which would use that information, but maybe someone else has ideas. Optimizer/codegen support coming soon. llvm-svn: 136404
2011-07-29 05:48:00 +08:00
case AtomicCmpXchg: return "cmpxchg";
case AtomicRMW: return "atomicrmw";
Initial implementation of 'fence' instruction, the new C++0x-style replacement for llvm.memory.barrier. This is just a LangRef entry and reading/writing/memory representation; optimizer+codegen support coming soon. llvm-svn: 136009
2011-07-26 07:16:38 +08:00
case Fence: return "fence";
Create a static version of Instruction::getOpcodeName(opCode) that can be invoked with only an opcode (i.e., without an instruction). Move all opCode->opCodeName translations there. llvm-svn: 2900
2002-07-15 07:09:40 +08:00
case GetElementPtr: return "getelementptr";
Remove trailing whitespace llvm-svn: 21427
2005-04-22 07:48:37 +08:00
For PR950: The long awaited CAST patch. This introduces 12 new instructions into LLVM to replace the cast instruction. Corresponding changes throughout LLVM are provided. This passes llvm-test, llvm/test, and SPEC CPUINT2000 with the exception of 175.vpr which fails only on a slight floating point output difference. llvm-svn: 31931
2006-11-27 09:05:10 +08:00
// Convert instructions...
Add addrspacecast instruction. Patch by Michele Scandale! llvm-svn: 194760
2013-11-15 09:34:59 +08:00
case Trunc: return "trunc";
case ZExt: return "zext";
case SExt: return "sext";
case FPTrunc: return "fptrunc";
case FPExt: return "fpext";
case FPToUI: return "fptoui";
case FPToSI: return "fptosi";
case UIToFP: return "uitofp";
case SIToFP: return "sitofp";
case IntToPtr: return "inttoptr";
case PtrToInt: return "ptrtoint";
case BitCast: return "bitcast";
case AddrSpaceCast: return "addrspacecast";
For PR950: The long awaited CAST patch. This introduces 12 new instructions into LLVM to replace the cast instruction. Corresponding changes throughout LLVM are provided. This passes llvm-test, llvm/test, and SPEC CPUINT2000 with the exception of 175.vpr which fails only on a slight floating point output difference. llvm-svn: 31931
2006-11-27 09:05:10 +08:00
Create a static version of Instruction::getOpcodeName(opCode) that can be invoked with only an opcode (i.e., without an instruction). Move all opCode->opCodeName translations there. llvm-svn: 2900
2002-07-15 07:09:40 +08:00
// Other instructions...
Allow the ICmp and FCmp instructions to be written by the AsmWriter llvm-svn: 32148
2006-12-03 14:27:29 +08:00
case ICmp: return "icmp";
case FCmp: return "fcmp";
For PR950: The long awaited CAST patch. This introduces 12 new instructions into LLVM to replace the cast instruction. Corresponding changes throughout LLVM are provided. This passes llvm-test, llvm/test, and SPEC CPUINT2000 with the exception of 175.vpr which fails only on a slight floating point output difference. llvm-svn: 31931
2006-11-27 09:05:10 +08:00
case PHI: return "phi";
case Select: return "select";
case Call: return "call";
case Shl: return "shl";
case LShr: return "lshr";
case AShr: return "ashr";
case VAArg: return "va_arg";
Added support for the extractelement operation. llvm-svn: 25181
2006-01-11 03:05:34 +08:00
case ExtractElement: return "extractelement";
For PR950: The long awaited CAST patch. This introduces 12 new instructions into LLVM to replace the cast instruction. Corresponding changes throughout LLVM are provided. This passes llvm-test, llvm/test, and SPEC CPUINT2000 with the exception of 175.vpr which fails only on a slight floating point output difference. llvm-svn: 31931
2006-11-27 09:05:10 +08:00
case InsertElement: return "insertelement";
case ShuffleVector: return "shufflevector";
Let Instruction::getOpcodeName() return something useful for the new insertvalue / extractvalue instructions. llvm-svn: 51766
2008-05-30 18:31:54 +08:00
case ExtractValue: return "extractvalue";
case InsertValue: return "insertvalue";
Initial commit of the 'landingpad' instruction. This implements the 'landingpad' instruction. It's used to indicate that a basic block is a landing pad. There are several restrictions on its use (see LangRef.html for more detail). These restrictions allow the exception handling code to gather the information it needs in a much more sane way. This patch has the definition, implementation, C interface, parsing, and bitcode support in it. llvm-svn: 137501
2011-08-13 04:24:12 +08:00
case LandingPad: return "landingpad";
[WinEH] Require token linkage in EH pad/ret signatures Summary: WinEHPrepare is going to require that cleanuppad and catchpad produce values of token type which are consumed by any cleanupret or catchret exiting the pad. This change updates the signatures of those operators to require/enforce that the type produced by the pads is token type and that the rets have an appropriate argument. The catchpad argument of a `CatchReturnInst` must be a `CatchPadInst` (and similarly for `CleanupReturnInst`/`CleanupPadInst`). To accommodate that restriction, this change adds a notion of an operator constraint to both LLParser and BitcodeReader, allowing appropriate sentinels to be constructed for forward references and appropriate error messages to be emitted for illegal inputs. Also add a verifier rule (noted in LangRef) that a catchpad with a catchpad predecessor must have no other predecessors; this ensures that WinEHPrepare will see the expected linear relationship between sibling catches on the same try. Lastly, remove some superfluous/vestigial casts from instruction operand setters operating on BasicBlocks. Reviewers: rnk, majnemer Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D12108 llvm-svn: 245797
2015-08-23 08:26:33 +08:00
case CleanupPad: return "cleanuppad";
Add support for the new va_arg instruction llvm-svn: 6029
2003-05-08 10:44:12 +08:00
Create a static version of Instruction::getOpcodeName(opCode) that can be invoked with only an opcode (i.e., without an instruction). Move all opCode->opCodeName translations there. llvm-svn: 2900
2002-07-15 07:09:40 +08:00
default: return "<Invalid operator> ";
}
}
New isAssociative/isCommutative inspection methods, graciously contributed by Casey Carter. llvm-svn: 4459
2002-10-31 12:14:01 +08:00
fix documentation comments; NFC llvm-svn: 283361
2016-10-06 02:51:12 +08:00
/// Return true if both instructions have the same special state. This must be
NFC: keep comment up to date MergeFunctions was refactored a while ago, and Instruction.cpp's comments went out of sync. The content did as well, will fix later. llvm-svn: 266007
2016-04-12 06:30:37 +08:00
/// kept in sync with FunctionComparator::cmpOperations in
/// lib/Transforms/IPO/MergeFunctions.cpp.
Factor out comparison of Instruction "special" states. No functional change. llvm-svn: 209688
2014-05-28 05:35:46 +08:00
static bool haveSameSpecialState(const Instruction *I1, const Instruction *I2,
bool IgnoreAlignment = false) {
assert(I1->getOpcode() == I2->getOpcode() &&
"Can not compare special state of different instructions");
Check alloca's special state Following up to a similar fix in MergeFunctions: r266022. This patch keeps both in sync, it would be nice to not have to do this. It doesn't look like there's an easy way to test this code directly at the moment: AFAICT all currect uses of isSameOperationAs are looking at instructions deep inside a function. IndVarSimplify/pr24952.ll and InstMerge/st_sink_* look at alloca inadvertently but are brittle tests. llvm-svn: 266099
2016-04-13 02:06:55 +08:00
if (const AllocaInst *AI = dyn_cast<AllocaInst>(I1))
return AI->getAllocatedType() == cast<AllocaInst>(I2)->getAllocatedType() &&
(AI->getAlignment() == cast<AllocaInst>(I2)->getAlignment() ||
IgnoreAlignment);
Factor out comparison of Instruction "special" states. No functional change. llvm-svn: 209688
2014-05-28 05:35:46 +08:00
if (const LoadInst *LI = dyn_cast<LoadInst>(I1))
return LI->isVolatile() == cast<LoadInst>(I2)->isVolatile() &&
(LI->getAlignment() == cast<LoadInst>(I2)->getAlignment() ||
IgnoreAlignment) &&
LI->getOrdering() == cast<LoadInst>(I2)->getOrdering() &&
Enhance synchscope representation OpenCL 2.0 introduces the notion of memory scopes in atomic operations to global and local memory. These scopes restrict how synchronization is achieved, which can result in improved performance. This change extends existing notion of synchronization scopes in LLVM to support arbitrary scopes expressed as target-specific strings, in addition to the already defined scopes (single thread, system). The LLVM IR and MIR syntax for expressing synchronization scopes has changed to use *syncscope("<scope>")*, where <scope> can be "singlethread" (this replaces *singlethread* keyword), or a target-specific name. As before, if the scope is not specified, it defaults to CrossThread/System scope. Implementation details: - Mapping from synchronization scope name/string to synchronization scope id is stored in LLVM context; - CrossThread/System and SingleThread scopes are pre-defined to efficiently check for known scopes without comparing strings; - Synchronization scope names are stored in SYNC_SCOPE_NAMES_BLOCK in the bitcode. Differential Revision: https://reviews.llvm.org/D21723 llvm-svn: 307722
2017-07-12 06:23:00 +08:00
LI->getSyncScopeID() == cast<LoadInst>(I2)->getSyncScopeID();
Factor out comparison of Instruction "special" states. No functional change. llvm-svn: 209688
2014-05-28 05:35:46 +08:00
if (const StoreInst *SI = dyn_cast<StoreInst>(I1))
return SI->isVolatile() == cast<StoreInst>(I2)->isVolatile() &&
(SI->getAlignment() == cast<StoreInst>(I2)->getAlignment() ||
IgnoreAlignment) &&
SI->getOrdering() == cast<StoreInst>(I2)->getOrdering() &&
Enhance synchscope representation OpenCL 2.0 introduces the notion of memory scopes in atomic operations to global and local memory. These scopes restrict how synchronization is achieved, which can result in improved performance. This change extends existing notion of synchronization scopes in LLVM to support arbitrary scopes expressed as target-specific strings, in addition to the already defined scopes (single thread, system). The LLVM IR and MIR syntax for expressing synchronization scopes has changed to use *syncscope("<scope>")*, where <scope> can be "singlethread" (this replaces *singlethread* keyword), or a target-specific name. As before, if the scope is not specified, it defaults to CrossThread/System scope. Implementation details: - Mapping from synchronization scope name/string to synchronization scope id is stored in LLVM context; - CrossThread/System and SingleThread scopes are pre-defined to efficiently check for known scopes without comparing strings; - Synchronization scope names are stored in SYNC_SCOPE_NAMES_BLOCK in the bitcode. Differential Revision: https://reviews.llvm.org/D21723 llvm-svn: 307722
2017-07-12 06:23:00 +08:00
SI->getSyncScopeID() == cast<StoreInst>(I2)->getSyncScopeID();
Factor out comparison of Instruction "special" states. No functional change. llvm-svn: 209688
2014-05-28 05:35:46 +08:00
if (const CmpInst *CI = dyn_cast<CmpInst>(I1))
return CI->getPredicate() == cast<CmpInst>(I2)->getPredicate();
if (const CallInst *CI = dyn_cast<CallInst>(I1))
return CI->isTailCall() == cast<CallInst>(I2)->isTailCall() &&
CI->getCallingConv() == cast<CallInst>(I2)->getCallingConv() &&
Teach haveSameSpecialState about operand bundles llvm-svn: 255527
2015-12-15 03:11:35 +08:00
CI->getAttributes() == cast<CallInst>(I2)->getAttributes() &&
CI->hasIdenticalOperandBundleSchema(*cast<CallInst>(I2));
Factor out comparison of Instruction "special" states. No functional change. llvm-svn: 209688
2014-05-28 05:35:46 +08:00
if (const InvokeInst *CI = dyn_cast<InvokeInst>(I1))
return CI->getCallingConv() == cast<InvokeInst>(I2)->getCallingConv() &&
Teach haveSameSpecialState about operand bundles llvm-svn: 255527
2015-12-15 03:11:35 +08:00
CI->getAttributes() == cast<InvokeInst>(I2)->getAttributes() &&
CI->hasIdenticalOperandBundleSchema(*cast<InvokeInst>(I2));
Factor out comparison of Instruction "special" states. No functional change. llvm-svn: 209688
2014-05-28 05:35:46 +08:00
if (const InsertValueInst *IVI = dyn_cast<InsertValueInst>(I1))
return IVI->getIndices() == cast<InsertValueInst>(I2)->getIndices();
if (const ExtractValueInst *EVI = dyn_cast<ExtractValueInst>(I1))
return EVI->getIndices() == cast<ExtractValueInst>(I2)->getIndices();
if (const FenceInst *FI = dyn_cast<FenceInst>(I1))
return FI->getOrdering() == cast<FenceInst>(I2)->getOrdering() &&
Enhance synchscope representation OpenCL 2.0 introduces the notion of memory scopes in atomic operations to global and local memory. These scopes restrict how synchronization is achieved, which can result in improved performance. This change extends existing notion of synchronization scopes in LLVM to support arbitrary scopes expressed as target-specific strings, in addition to the already defined scopes (single thread, system). The LLVM IR and MIR syntax for expressing synchronization scopes has changed to use *syncscope("<scope>")*, where <scope> can be "singlethread" (this replaces *singlethread* keyword), or a target-specific name. As before, if the scope is not specified, it defaults to CrossThread/System scope. Implementation details: - Mapping from synchronization scope name/string to synchronization scope id is stored in LLVM context; - CrossThread/System and SingleThread scopes are pre-defined to efficiently check for known scopes without comparing strings; - Synchronization scope names are stored in SYNC_SCOPE_NAMES_BLOCK in the bitcode. Differential Revision: https://reviews.llvm.org/D21723 llvm-svn: 307722
2017-07-12 06:23:00 +08:00
FI->getSyncScopeID() == cast<FenceInst>(I2)->getSyncScopeID();
Factor out comparison of Instruction "special" states. No functional change. llvm-svn: 209688
2014-05-28 05:35:46 +08:00
if (const AtomicCmpXchgInst *CXI = dyn_cast<AtomicCmpXchgInst>(I1))
return CXI->isVolatile() == cast<AtomicCmpXchgInst>(I2)->isVolatile() &&
IR: add "cmpxchg weak" variant to support permitted failure. This commit adds a weak variant of the cmpxchg operation, as described in C++11. A cmpxchg instruction with this modifier is permitted to fail to store, even if the comparison indicated it should. As a result, cmpxchg instructions must return a flag indicating success in addition to their original iN value loaded. Thus, for uniformity *all* cmpxchg instructions now return "{ iN, i1 }". The second flag is 1 when the store succeeded. At the DAG level, a new ATOMIC_CMP_SWAP_WITH_SUCCESS node has been added as the natural representation for the new cmpxchg instructions. It is a strong cmpxchg. By default this gets Expanded to the existing ATOMIC_CMP_SWAP during Legalization, so existing backends should see no change in behaviour. If they wish to deal with the enhanced node instead, they can call setOperationAction on it. Beware: as a node with 2 results, it cannot be selected from TableGen. Currently, no use is made of the extra information provided in this patch. Test updates are almost entirely adapting the input IR to the new scheme. Summary for out of tree users: ------------------------------ + Legacy Bitcode files are upgraded during read. + Legacy assembly IR files will be invalid. + Front-ends must adapt to different type for "cmpxchg". + Backends should be unaffected by default. llvm-svn: 210903
2014-06-13 22:24:07 +08:00
CXI->isWeak() == cast<AtomicCmpXchgInst>(I2)->isWeak() &&
Factor out comparison of Instruction "special" states. No functional change. llvm-svn: 209688
2014-05-28 05:35:46 +08:00
CXI->getSuccessOrdering() ==
cast<AtomicCmpXchgInst>(I2)->getSuccessOrdering() &&
CXI->getFailureOrdering() ==
cast<AtomicCmpXchgInst>(I2)->getFailureOrdering() &&
Enhance synchscope representation OpenCL 2.0 introduces the notion of memory scopes in atomic operations to global and local memory. These scopes restrict how synchronization is achieved, which can result in improved performance. This change extends existing notion of synchronization scopes in LLVM to support arbitrary scopes expressed as target-specific strings, in addition to the already defined scopes (single thread, system). The LLVM IR and MIR syntax for expressing synchronization scopes has changed to use *syncscope("<scope>")*, where <scope> can be "singlethread" (this replaces *singlethread* keyword), or a target-specific name. As before, if the scope is not specified, it defaults to CrossThread/System scope. Implementation details: - Mapping from synchronization scope name/string to synchronization scope id is stored in LLVM context; - CrossThread/System and SingleThread scopes are pre-defined to efficiently check for known scopes without comparing strings; - Synchronization scope names are stored in SYNC_SCOPE_NAMES_BLOCK in the bitcode. Differential Revision: https://reviews.llvm.org/D21723 llvm-svn: 307722
2017-07-12 06:23:00 +08:00
CXI->getSyncScopeID() ==
cast<AtomicCmpXchgInst>(I2)->getSyncScopeID();
Factor out comparison of Instruction "special" states. No functional change. llvm-svn: 209688
2014-05-28 05:35:46 +08:00
if (const AtomicRMWInst *RMWI = dyn_cast<AtomicRMWInst>(I1))
return RMWI->getOperation() == cast<AtomicRMWInst>(I2)->getOperation() &&
RMWI->isVolatile() == cast<AtomicRMWInst>(I2)->isVolatile() &&
RMWI->getOrdering() == cast<AtomicRMWInst>(I2)->getOrdering() &&
Enhance synchscope representation OpenCL 2.0 introduces the notion of memory scopes in atomic operations to global and local memory. These scopes restrict how synchronization is achieved, which can result in improved performance. This change extends existing notion of synchronization scopes in LLVM to support arbitrary scopes expressed as target-specific strings, in addition to the already defined scopes (single thread, system). The LLVM IR and MIR syntax for expressing synchronization scopes has changed to use *syncscope("<scope>")*, where <scope> can be "singlethread" (this replaces *singlethread* keyword), or a target-specific name. As before, if the scope is not specified, it defaults to CrossThread/System scope. Implementation details: - Mapping from synchronization scope name/string to synchronization scope id is stored in LLVM context; - CrossThread/System and SingleThread scopes are pre-defined to efficiently check for known scopes without comparing strings; - Synchronization scope names are stored in SYNC_SCOPE_NAMES_BLOCK in the bitcode. Differential Revision: https://reviews.llvm.org/D21723 llvm-svn: 307722
2017-07-12 06:23:00 +08:00
RMWI->getSyncScopeID() == cast<AtomicRMWInst>(I2)->getSyncScopeID();
Factor out comparison of Instruction "special" states. No functional change. llvm-svn: 209688
2014-05-28 05:35:46 +08:00
return true;
}
improve const correctness. llvm-svn: 60168
2008-11-27 16:39:18 +08:00
bool Instruction::isIdenticalTo(const Instruction *I) const {
This should use isIndenticalToWhenDefined. llvm-svn: 80039
2009-08-26 06:24:20 +08:00
return isIdenticalToWhenDefined(I) &&
Rename Instruction::isIdenticalTo to Instruction::isIdenticalToWhenDefined, and introduce a new Instruction::isIdenticalTo which tests for full identity, including the SubclassOptionalData flags. Also, fix the Instruction::clone implementations to preserve the SubclassOptionalData flags. Finally, teach several optimizations how to handle SubclassOptionalData correctly, given these changes. This fixes the counterintuitive behavior of isIdenticalTo not comparing the full value, and clone not returning an identical clone, as well as some subtle bugs that could be caused by these. Thanks to Nick Lewycky for reporting this, and for an initial patch! llvm-svn: 80038
2009-08-26 06:11:20 +08:00
SubclassOptionalData == I->SubclassOptionalData;
}
bool Instruction::isIdenticalToWhenDefined(const Instruction *I) const {
Add method llvm-svn: 18368
2004-11-30 10:51:53 +08:00
if (getOpcode() != I->getOpcode() ||
getNumOperands() != I->getNumOperands() ||
getType() != I->getType())
return false;
Instruction::isIdenticalToWhenDefined(): Check getNumOperands() in advance of std::equal(op) to appease MSVC Debug build. MSVC Debug build is confused with (possibly invalid) op_begin(), if op_begin() == op_end(). llvm-svn: 210000
2014-06-02 09:35:34 +08:00
// If both instructions have no operands, they are identical.
if (getNumOperands() == 0 && I->getNumOperands() == 0)
return haveSameSpecialState(this, I);
Add method llvm-svn: 18368
2004-11-30 10:51:53 +08:00
// We have two instructions of identical opcode and #operands. Check to see
// if all operands are the same.
[C++11] Modernize the IR library a bit. No functionality change. llvm-svn: 203465
2014-03-10 23:03:06 +08:00
if (!std::equal(op_begin(), op_end(), I->op_begin()))
return false;
Add method llvm-svn: 18368
2004-11-30 10:51:53 +08:00
Fix a problem with incomplete equality testing of PHINodes in Instruction::IsIdenticalToWhenDefined. This manifested itself when inlining two calls to the same function. The inlined function had a switch statement that returned one of a set of global variables. Without this modification, the two phi instructions that chose values from the branches of the switch instruction inlined from the callee were considered equivalent and jump-threading replaced a load for the first switch value with a phi selecting from the second switch, thereby producing incorrect code. This patch has been tested with "make check-all", "lnt runteste nt", and llvm self-hosted, and on the original program that had this problem, wireshark. <rdar://problem/11025519> llvm-svn: 156548
2012-05-10 23:59:41 +08:00
if (const PHINode *thisPHI = dyn_cast<PHINode>(this)) {
const PHINode *otherPHI = cast<PHINode>(I);
[C++11] Modernize the IR library a bit. No functionality change. llvm-svn: 203465
2014-03-10 23:03:06 +08:00
return std::equal(thisPHI->block_begin(), thisPHI->block_end(),
otherPHI->block_begin());
Fix a problem with incomplete equality testing of PHINodes in Instruction::IsIdenticalToWhenDefined. This manifested itself when inlining two calls to the same function. The inlined function had a switch statement that returned one of a set of global variables. Without this modification, the two phi instructions that chose values from the branches of the switch instruction inlined from the callee were considered equivalent and jump-threading replaced a load for the first switch value with a phi selecting from the second switch, thereby producing incorrect code. This patch has been tested with "make check-all", "lnt runteste nt", and llvm self-hosted, and on the original program that had this problem, wireshark. <rdar://problem/11025519> llvm-svn: 156548
2012-05-10 23:59:41 +08:00
}
Factor out comparison of Instruction "special" states. No functional change. llvm-svn: 209688
2014-05-28 05:35:46 +08:00
return haveSameSpecialState(this, I);
For PR950: This patch removes the SetCC instructions and replaces them with the ICmp and FCmp instructions. The SetCondInst instruction has been removed and been replaced with ICmpInst and FCmpInst. llvm-svn: 32751
2006-12-23 14:05:41 +08:00
}
NFC: keep comment up to date MergeFunctions was refactored a while ago, and Instruction.cpp's comments went out of sync. The content did as well, will fix later. llvm-svn: 266007
2016-04-12 06:30:37 +08:00
// Keep this in sync with FunctionComparator::cmpOperations in
Give Instruction::isSameOperationAs a corresponding comment to note the relationship with MergeFunctions.cpp's isEquivalentOperation, and make a trivial code reordering so that the two functions are easier to compare. Fix the name of Instruction::isSameOperationAs in MergeFunction.cpp's isEquivalentOperation's comment, and fix a nearby 80-column violation. llvm-svn: 73241
2009-06-13 03:03:05 +08:00
// lib/Transforms/IPO/MergeFunctions.cpp.
Refactor operation equivalence checking in BBVectorize by extending Instruction::isSameOperationAs. Maintaining this kind of checking in different places is dangerous, extending Instruction::isSameOperationAs consolidates this logic into one place. Here I've added an optional flags parameter and two flags that are important for vectorization: CompareIgnoringAlignment and CompareUsingScalarTypes. llvm-svn: 159329
2012-06-28 13:42:26 +08:00
bool Instruction::isSameOperationAs(const Instruction *I,
unsigned flags) const {
bool IgnoreAlignment = flags & CompareIgnoringAlignment;
bool UseScalarTypes = flags & CompareUsingScalarTypes;
Give Instruction::isSameOperationAs a corresponding comment to note the relationship with MergeFunctions.cpp's isEquivalentOperation, and make a trivial code reordering so that the two functions are easier to compare. Fix the name of Instruction::isSameOperationAs in MergeFunction.cpp's isEquivalentOperation's comment, and fix a nearby 80-column violation. llvm-svn: 73241
2009-06-13 03:03:05 +08:00
if (getOpcode() != I->getOpcode() ||
getNumOperands() != I->getNumOperands() ||
Refactor operation equivalence checking in BBVectorize by extending Instruction::isSameOperationAs. Maintaining this kind of checking in different places is dangerous, extending Instruction::isSameOperationAs consolidates this logic into one place. Here I've added an optional flags parameter and two flags that are important for vectorization: CompareIgnoringAlignment and CompareUsingScalarTypes. llvm-svn: 159329
2012-06-28 13:42:26 +08:00
(UseScalarTypes ?
getType()->getScalarType() != I->getType()->getScalarType() :
getType() != I->getType()))
For PR950: This patch removes the SetCC instructions and replaces them with the ICmp and FCmp instructions. The SetCondInst instruction has been removed and been replaced with ICmpInst and FCmpInst. llvm-svn: 32751
2006-12-23 14:05:41 +08:00
return false;
// We have two instructions of identical opcode and #operands. Check to see
// if all operands are the same type
for (unsigned i = 0, e = getNumOperands(); i != e; ++i)
Refactor operation equivalence checking in BBVectorize by extending Instruction::isSameOperationAs. Maintaining this kind of checking in different places is dangerous, extending Instruction::isSameOperationAs consolidates this logic into one place. Here I've added an optional flags parameter and two flags that are important for vectorization: CompareIgnoringAlignment and CompareUsingScalarTypes. llvm-svn: 159329
2012-06-28 13:42:26 +08:00
if (UseScalarTypes ?
getOperand(i)->getType()->getScalarType() !=
I->getOperand(i)->getType()->getScalarType() :
getOperand(i)->getType() != I->getOperand(i)->getType())
For PR950: This patch removes the SetCC instructions and replaces them with the ICmp and FCmp instructions. The SetCondInst instruction has been removed and been replaced with ICmpInst and FCmpInst. llvm-svn: 32751
2006-12-23 14:05:41 +08:00
return false;
Factor out comparison of Instruction "special" states. No functional change. llvm-svn: 209688
2014-05-28 05:35:46 +08:00
return haveSameSpecialState(this, I, IgnoreAlignment);
Add method llvm-svn: 18368
2004-11-30 10:51:53 +08:00
}
add a handy helper method to instruction, useful for determining whether it is used outside of some block. This can be used to see if there are any non-local references, for example. llvm-svn: 50004
2008-04-21 06:11:30 +08:00
bool Instruction::isUsedOutsideOfBlock(const BasicBlock *BB) const {
[C++11] Add range based accessors for the Use-Def chain of a Value. This requires a number of steps. 1) Move value_use_iterator into the Value class as an implementation detail 2) Change it to actually be a *Use* iterator rather than a *User* iterator. 3) Add an adaptor which is a User iterator that always looks through the Use to the User. 4) Wrap these in Value::use_iterator and Value::user_iterator typedefs. 5) Add the range adaptors as Value::uses() and Value::users(). 6) Update *all* of the callers to correctly distinguish between whether they wanted a use_iterator (and to explicitly dig out the User when needed), or a user_iterator which makes the Use itself totally opaque. Because #6 requires churning essentially everything that walked the Use-Def chains, I went ahead and added all of the range adaptors and switched them to range-based loops where appropriate. Also because the renaming requires at least churning every line of code, it didn't make any sense to split these up into multiple commits -- all of which would touch all of the same lies of code. The result is still not quite optimal. The Value::use_iterator is a nice regular iterator, but Value::user_iterator is an iterator over User*s rather than over the User objects themselves. As a consequence, it fits a bit awkwardly into the range-based world and it has the weird extra-dereferencing 'operator->' that so many of our iterators have. I think this could be fixed by providing something which transforms a range of T&s into a range of T*s, but that *can* be separated into another patch, and it isn't yet 100% clear whether this is the right move. However, this change gets us most of the benefit and cleans up a substantial amount of code around Use and User. =] llvm-svn: 203364
2014-03-09 11:16:01 +08:00
for (const Use &U : uses()) {
add a handy helper method to instruction, useful for determining whether it is used outside of some block. This can be used to see if there are any non-local references, for example. llvm-svn: 50004
2008-04-21 06:11:30 +08:00
// PHI nodes uses values in the corresponding predecessor block. For other
// instructions, just check to see whether the parent of the use matches up.
[C++11] Add range based accessors for the Use-Def chain of a Value. This requires a number of steps. 1) Move value_use_iterator into the Value class as an implementation detail 2) Change it to actually be a *Use* iterator rather than a *User* iterator. 3) Add an adaptor which is a User iterator that always looks through the Use to the User. 4) Wrap these in Value::use_iterator and Value::user_iterator typedefs. 5) Add the range adaptors as Value::uses() and Value::users(). 6) Update *all* of the callers to correctly distinguish between whether they wanted a use_iterator (and to explicitly dig out the User when needed), or a user_iterator which makes the Use itself totally opaque. Because #6 requires churning essentially everything that walked the Use-Def chains, I went ahead and added all of the range adaptors and switched them to range-based loops where appropriate. Also because the renaming requires at least churning every line of code, it didn't make any sense to split these up into multiple commits -- all of which would touch all of the same lies of code. The result is still not quite optimal. The Value::use_iterator is a nice regular iterator, but Value::user_iterator is an iterator over User*s rather than over the User objects themselves. As a consequence, it fits a bit awkwardly into the range-based world and it has the weird extra-dereferencing 'operator->' that so many of our iterators have. I think this could be fixed by providing something which transforms a range of T&s into a range of T*s, but that *can* be separated into another patch, and it isn't yet 100% clear whether this is the right move. However, this change gets us most of the benefit and cleans up a substantial amount of code around Use and User. =] llvm-svn: 203364
2014-03-09 11:16:01 +08:00
const Instruction *I = cast<Instruction>(U.getUser());
const PHINode *PN = dyn_cast<PHINode>(I);
[C++11] More 'nullptr' conversion or in some cases just using a boolean check instead of comparing to nullptr. llvm-svn: 205831
2014-04-09 14:08:46 +08:00
if (!PN) {
[C++11] Add range based accessors for the Use-Def chain of a Value. This requires a number of steps. 1) Move value_use_iterator into the Value class as an implementation detail 2) Change it to actually be a *Use* iterator rather than a *User* iterator. 3) Add an adaptor which is a User iterator that always looks through the Use to the User. 4) Wrap these in Value::use_iterator and Value::user_iterator typedefs. 5) Add the range adaptors as Value::uses() and Value::users(). 6) Update *all* of the callers to correctly distinguish between whether they wanted a use_iterator (and to explicitly dig out the User when needed), or a user_iterator which makes the Use itself totally opaque. Because #6 requires churning essentially everything that walked the Use-Def chains, I went ahead and added all of the range adaptors and switched them to range-based loops where appropriate. Also because the renaming requires at least churning every line of code, it didn't make any sense to split these up into multiple commits -- all of which would touch all of the same lies of code. The result is still not quite optimal. The Value::use_iterator is a nice regular iterator, but Value::user_iterator is an iterator over User*s rather than over the User objects themselves. As a consequence, it fits a bit awkwardly into the range-based world and it has the weird extra-dereferencing 'operator->' that so many of our iterators have. I think this could be fixed by providing something which transforms a range of T&s into a range of T*s, but that *can* be separated into another patch, and it isn't yet 100% clear whether this is the right move. However, this change gets us most of the benefit and cleans up a substantial amount of code around Use and User. =] llvm-svn: 203364
2014-03-09 11:16:01 +08:00
if (I->getParent() != BB)
add a handy helper method to instruction, useful for determining whether it is used outside of some block. This can be used to see if there are any non-local references, for example. llvm-svn: 50004
2008-04-21 06:11:30 +08:00
return true;
continue;
}
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
[C++11] Add range based accessors for the Use-Def chain of a Value. This requires a number of steps. 1) Move value_use_iterator into the Value class as an implementation detail 2) Change it to actually be a *Use* iterator rather than a *User* iterator. 3) Add an adaptor which is a User iterator that always looks through the Use to the User. 4) Wrap these in Value::use_iterator and Value::user_iterator typedefs. 5) Add the range adaptors as Value::uses() and Value::users(). 6) Update *all* of the callers to correctly distinguish between whether they wanted a use_iterator (and to explicitly dig out the User when needed), or a user_iterator which makes the Use itself totally opaque. Because #6 requires churning essentially everything that walked the Use-Def chains, I went ahead and added all of the range adaptors and switched them to range-based loops where appropriate. Also because the renaming requires at least churning every line of code, it didn't make any sense to split these up into multiple commits -- all of which would touch all of the same lies of code. The result is still not quite optimal. The Value::use_iterator is a nice regular iterator, but Value::user_iterator is an iterator over User*s rather than over the User objects themselves. As a consequence, it fits a bit awkwardly into the range-based world and it has the weird extra-dereferencing 'operator->' that so many of our iterators have. I think this could be fixed by providing something which transforms a range of T&s into a range of T*s, but that *can* be separated into another patch, and it isn't yet 100% clear whether this is the right move. However, this change gets us most of the benefit and cleans up a substantial amount of code around Use and User. =] llvm-svn: 203364
2014-03-09 11:16:01 +08:00
if (PN->getIncomingBlock(U) != BB)
add a handy helper method to instruction, useful for determining whether it is used outside of some block. This can be used to see if there are any non-local references, for example. llvm-svn: 50004
2008-04-21 06:11:30 +08:00
return true;
}
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
return false;
add a handy helper method to instruction, useful for determining whether it is used outside of some block. This can be used to see if there are any non-local references, for example. llvm-svn: 50004
2008-04-21 06:11:30 +08:00
}
add a new Instruction::mayReadFromMemory predicate, make Instruction::mayWriteToMemory stronger for invokes. llvm-svn: 50858
2008-05-09 01:16:51 +08:00
bool Instruction::mayReadFromMemory() const {
switch (getOpcode()) {
default: return false;
case Instruction::VAArg:
conservatively say that volatile stores read memory. llvm-svn: 50872
2008-05-09 05:58:49 +08:00
case Instruction::Load:
Misc mid-level changes for new 'fence' instruction. llvm-svn: 136205
2011-07-27 09:08:30 +08:00
case Instruction::Fence: // FIXME: refine definition of mayReadFromMemory
Misc optimizer+codegen work for 'cmpxchg' and 'atomicrmw'. They appear to be working on x86 (at least for trivial testcases); other architectures will need more work so that they actually emit the appropriate instructions for orderings stricter than 'monotonic'. (As far as I can tell, the ARM, PPC, Mips, and Alpha backends need such changes.) llvm-svn: 136457
2011-07-29 11:05:32 +08:00
case Instruction::AtomicCmpXchg:
case Instruction::AtomicRMW:
[IR] Conservatively mark 'catchpad' as accessing memory The exact semantics of 'catchpad' are really in the hands of the personality routine so we shouldn't assume that they have no side effects. llvm-svn: 247322
2015-09-11 02:50:09 +08:00
case Instruction::CatchPad:
New EH representation for MSVC compatibility This introduces new instructions neccessary to implement MSVC-compatible exception handling support. Most of the middle-end and none of the back-end haven't been audited or updated to take them into account. Differential Revision: http://reviews.llvm.org/D11097 llvm-svn: 243766
2015-08-01 01:58:14 +08:00
case Instruction::CatchRet:
add a new Instruction::mayReadFromMemory predicate, make Instruction::mayWriteToMemory stronger for invokes. llvm-svn: 50858
2008-05-09 01:16:51 +08:00
return true;
case Instruction::Call:
return !cast<CallInst>(this)->doesNotAccessMemory();
case Instruction::Invoke:
return !cast<InvokeInst>(this)->doesNotAccessMemory();
conservatively say that volatile stores read memory. llvm-svn: 50872
2008-05-09 05:58:49 +08:00
case Instruction::Store:
Fix predicates methods on Instruction to handle atomic load/store correctly. llvm-svn: 137652
2011-08-16 05:00:18 +08:00
return !cast<StoreInst>(this)->isUnordered();
add a new Instruction::mayReadFromMemory predicate, make Instruction::mayWriteToMemory stronger for invokes. llvm-svn: 50858
2008-05-09 01:16:51 +08:00
}
}
add a handy helper method to instruction, useful for determining whether it is used outside of some block. This can be used to see if there are any non-local references, for example. llvm-svn: 50004
2008-04-21 06:11:30 +08:00
make mayWriteToMemory a non-virtual function llvm-svn: 34334
2007-02-16 07:15:00 +08:00
bool Instruction::mayWriteToMemory() const {
switch (getOpcode()) {
default: return false;
Misc mid-level changes for new 'fence' instruction. llvm-svn: 136205
2011-07-27 09:08:30 +08:00
case Instruction::Fence: // FIXME: refine definition of mayWriteToMemory
Rather than having special rules like "intrinsics cannot throw exceptions", just mark intrinsics with the nounwind attribute. Likewise, mark intrinsics as readnone/readonly and get rid of special aliasing logic (which didn't use anything more than this anyway). llvm-svn: 44544
2007-12-04 04:06:50 +08:00
case Instruction::Store:
make mayWriteToMemory a non-virtual function llvm-svn: 34334
2007-02-16 07:15:00 +08:00
case Instruction::VAArg:
Misc optimizer+codegen work for 'cmpxchg' and 'atomicrmw'. They appear to be working on x86 (at least for trivial testcases); other architectures will need more work so that they actually emit the appropriate instructions for orderings stricter than 'monotonic'. (As far as I can tell, the ARM, PPC, Mips, and Alpha backends need such changes.) llvm-svn: 136457
2011-07-29 11:05:32 +08:00
case Instruction::AtomicCmpXchg:
case Instruction::AtomicRMW:
[IR] Conservatively mark 'catchpad' as accessing memory The exact semantics of 'catchpad' are really in the hands of the personality routine so we shouldn't assume that they have no side effects. llvm-svn: 247322
2015-09-11 02:50:09 +08:00
case Instruction::CatchPad:
New EH representation for MSVC compatibility This introduces new instructions neccessary to implement MSVC-compatible exception handling support. Most of the middle-end and none of the back-end haven't been audited or updated to take them into account. Differential Revision: http://reviews.llvm.org/D11097 llvm-svn: 243766
2015-08-01 01:58:14 +08:00
case Instruction::CatchRet:
make mayWriteToMemory a non-virtual function llvm-svn: 34334
2007-02-16 07:15:00 +08:00
return true;
case Instruction::Call:
Rather than having special rules like "intrinsics cannot throw exceptions", just mark intrinsics with the nounwind attribute. Likewise, mark intrinsics as readnone/readonly and get rid of special aliasing logic (which didn't use anything more than this anyway). llvm-svn: 44544
2007-12-04 04:06:50 +08:00
return !cast<CallInst>(this)->onlyReadsMemory();
add a new Instruction::mayReadFromMemory predicate, make Instruction::mayWriteToMemory stronger for invokes. llvm-svn: 50858
2008-05-09 01:16:51 +08:00
case Instruction::Invoke:
return !cast<InvokeInst>(this)->onlyReadsMemory();
make mayWriteToMemory a non-virtual function llvm-svn: 34334
2007-02-16 07:15:00 +08:00
case Instruction::Load:
Fix predicates methods on Instruction to handle atomic load/store correctly. llvm-svn: 137652
2011-08-16 05:00:18 +08:00
return !cast<LoadInst>(this)->isUnordered();
make mayWriteToMemory a non-virtual function llvm-svn: 34334
2007-02-16 07:15:00 +08:00
}
}
New isAssociative/isCommutative inspection methods, graciously contributed by Casey Carter. llvm-svn: 4459
2002-10-31 12:14:01 +08:00
Refactor AtomicExpandPass and add a generic isAtomic() method to Instruction Summary: Split shouldExpandAtomicInIR() into different versions for Stores/Loads/RMWs/CmpXchgs. Makes runOnFunction cleaner (no more redundant checking/casting), and will help moving the X86 backend to this pass. This requires a way of easily detecting which instructions are atomic. I followed the pattern of mayReadFromMemory, mayWriteOrReadMemory, etc.. in making isAtomic() a method of Instruction implemented by a switch on the opcodes. Test Plan: make check Reviewers: jfb Subscribers: mcrosier, llvm-commits Differential Revision: http://reviews.llvm.org/D5035 llvm-svn: 217080
2014-09-04 05:29:59 +08:00
bool Instruction::isAtomic() const {
switch (getOpcode()) {
default:
return false;
case Instruction::AtomicCmpXchg:
case Instruction::AtomicRMW:
case Instruction::Fence:
return true;
case Instruction::Load:
NFC: make AtomicOrdering an enum class Summary: In the context of http://wg21.link/lwg2445 C++ uses the concept of 'stronger' ordering but doesn't define it properly. This should be fixed in C++17 barring a small question that's still open. The code currently plays fast and loose with the AtomicOrdering enum. Using an enum class is one step towards tightening things. I later also want to tighten related enums, such as clang's AtomicOrderingKind (which should be shared with LLVM as a 'C++ ABI' enum). This change touches a few lines of code which can be improved later, I'd like to keep it as NFC for now as it's already quite complex. I have related changes for clang. As a follow-up I'll add: bool operator<(AtomicOrdering, AtomicOrdering) = delete; bool operator>(AtomicOrdering, AtomicOrdering) = delete; bool operator<=(AtomicOrdering, AtomicOrdering) = delete; bool operator>=(AtomicOrdering, AtomicOrdering) = delete; This is separate so that clang and LLVM changes don't need to be in sync. Reviewers: jyknight, reames Subscribers: jyknight, llvm-commits Differential Revision: http://reviews.llvm.org/D18775 llvm-svn: 265602
2016-04-07 05:19:33 +08:00
return cast<LoadInst>(this)->getOrdering() != AtomicOrdering::NotAtomic;
Refactor AtomicExpandPass and add a generic isAtomic() method to Instruction Summary: Split shouldExpandAtomicInIR() into different versions for Stores/Loads/RMWs/CmpXchgs. Makes runOnFunction cleaner (no more redundant checking/casting), and will help moving the X86 backend to this pass. This requires a way of easily detecting which instructions are atomic. I followed the pattern of mayReadFromMemory, mayWriteOrReadMemory, etc.. in making isAtomic() a method of Instruction implemented by a switch on the opcodes. Test Plan: make check Reviewers: jfb Subscribers: mcrosier, llvm-commits Differential Revision: http://reviews.llvm.org/D5035 llvm-svn: 217080
2014-09-04 05:29:59 +08:00
case Instruction::Store:
NFC: make AtomicOrdering an enum class Summary: In the context of http://wg21.link/lwg2445 C++ uses the concept of 'stronger' ordering but doesn't define it properly. This should be fixed in C++17 barring a small question that's still open. The code currently plays fast and loose with the AtomicOrdering enum. Using an enum class is one step towards tightening things. I later also want to tighten related enums, such as clang's AtomicOrderingKind (which should be shared with LLVM as a 'C++ ABI' enum). This change touches a few lines of code which can be improved later, I'd like to keep it as NFC for now as it's already quite complex. I have related changes for clang. As a follow-up I'll add: bool operator<(AtomicOrdering, AtomicOrdering) = delete; bool operator>(AtomicOrdering, AtomicOrdering) = delete; bool operator<=(AtomicOrdering, AtomicOrdering) = delete; bool operator>=(AtomicOrdering, AtomicOrdering) = delete; This is separate so that clang and LLVM changes don't need to be in sync. Reviewers: jyknight, reames Subscribers: jyknight, llvm-commits Differential Revision: http://reviews.llvm.org/D18775 llvm-svn: 265602
2016-04-07 05:19:33 +08:00
return cast<StoreInst>(this)->getOrdering() != AtomicOrdering::NotAtomic;
Refactor AtomicExpandPass and add a generic isAtomic() method to Instruction Summary: Split shouldExpandAtomicInIR() into different versions for Stores/Loads/RMWs/CmpXchgs. Makes runOnFunction cleaner (no more redundant checking/casting), and will help moving the X86 backend to this pass. This requires a way of easily detecting which instructions are atomic. I followed the pattern of mayReadFromMemory, mayWriteOrReadMemory, etc.. in making isAtomic() a method of Instruction implemented by a switch on the opcodes. Test Plan: make check Reviewers: jfb Subscribers: mcrosier, llvm-commits Differential Revision: http://reviews.llvm.org/D5035 llvm-svn: 217080
2014-09-04 05:29:59 +08:00
}
}
[Atomic] Remove IsStore/IsLoad in the interface, and pass the instruction instead. NFC. Now both emitLeadingFence and emitTrailingFence take the instruction itself, instead of taking IsLoad/IsStore pairs. Instruction::mayReadFromMemory and Instrucion::mayWriteToMemory are used for determining those two booleans. The instruction argument is also useful for later D32763, in emitTrailingFence. For emitLeadingFence, it seems to have cleaner interface with the proposed change. Differential Revision: https://reviews.llvm.org/D32762 llvm-svn: 302539
2017-05-09 23:27:17 +08:00
bool Instruction::hasAtomicLoad() const {
assert(isAtomic());
switch (getOpcode()) {
default:
return false;
case Instruction::AtomicCmpXchg:
case Instruction::AtomicRMW:
case Instruction::Load:
return true;
}
}
bool Instruction::hasAtomicStore() const {
assert(isAtomic());
switch (getOpcode()) {
default:
return false;
case Instruction::AtomicCmpXchg:
case Instruction::AtomicRMW:
case Instruction::Store:
return true;
}
}
Allow readonly functions to unwind exceptions. Teach the optimizers about this. For example, a readonly function with no uses cannot be removed unless it is also marked nounwind. llvm-svn: 71071
2009-05-06 14:49:50 +08:00
bool Instruction::mayThrow() const {
if (const CallInst *CI = dyn_cast<CallInst>(this))
return !CI->doesNotThrow();
New EH representation for MSVC compatibility This introduces new instructions neccessary to implement MSVC-compatible exception handling support. Most of the middle-end and none of the back-end haven't been audited or updated to take them into account. Differential Revision: http://reviews.llvm.org/D11097 llvm-svn: 243766
2015-08-01 01:58:14 +08:00
if (const auto *CRI = dyn_cast<CleanupReturnInst>(this))
return CRI->unwindsToCaller();
[IR] Reformulate LLVM's EH funclet IR While we have successfully implemented a funclet-oriented EH scheme on top of LLVM IR, our scheme has some notable deficiencies: - catchendpad and cleanupendpad are necessary in the current design but they are difficult to explain to others, even to seasoned LLVM experts. - catchendpad and cleanupendpad are optimization barriers. They cannot be split and force all potentially throwing call-sites to be invokes. This has a noticable effect on the quality of our code generation. - catchpad, while similar in some aspects to invoke, is fairly awkward. It is unsplittable, starts a funclet, and has control flow to other funclets. - The nesting relationship between funclets is currently a property of control flow edges. Because of this, we are forced to carefully analyze the flow graph to see if there might potentially exist illegal nesting among funclets. While we have logic to clone funclets when they are illegally nested, it would be nicer if we had a representation which forbade them upfront. Let's clean this up a bit by doing the following: - Instead, make catchpad more like cleanuppad and landingpad: no control flow, just a bunch of simple operands; catchpad would be splittable. - Introduce catchswitch, a control flow instruction designed to model the constraints of funclet oriented EH. - Make funclet scoping explicit by having funclet instructions consume the token produced by the funclet which contains them. - Remove catchendpad and cleanupendpad. Their presence can be inferred implicitly using coloring information. N.B. The state numbering code for the CLR has been updated but the veracity of it's output cannot be spoken for. An expert should take a look to make sure the results are reasonable. Reviewers: rnk, JosephTremoulet, andrew.w.kaylor Differential Revision: http://reviews.llvm.org/D15139 llvm-svn: 255422
2015-12-12 13:38:55 +08:00
if (const auto *CatchSwitch = dyn_cast<CatchSwitchInst>(this))
return CatchSwitch->unwindsToCaller();
The resume instruction may throw. Return 'true' in this case. llvm-svn: 137757
2011-08-17 05:15:50 +08:00
return isa<ResumeInst>(this);
Allow readonly functions to unwind exceptions. Teach the optimizers about this. For example, a readonly function with no uses cannot be removed unless it is also marked nounwind. llvm-svn: 71071
2009-05-06 14:49:50 +08:00
}
Instruction::isAssociative() returns true for fmul/fadd if they are tagged "unsafe" mode. Approved by: Eli and Michael. llvm-svn: 168848
2012-11-29 09:47:31 +08:00
bool Instruction::isAssociative() const {
unsigned Opcode = getOpcode();
if (isAssociative(Opcode))
return true;
switch (Opcode) {
case FMul:
case FAdd:
return cast<FPMathOperator>(this)->hasUnsafeAlgebra();
default:
return false;
}
}
Devirtualize Instruction::clone_impl llvm-svn: 240588
2015-06-25 04:22:23 +08:00
Instruction *Instruction::cloneImpl() const {
llvm_unreachable("Subclass of Instruction failed to implement cloneImpl");
}
[Profile] refactor meta data copying/swapping code Differential Revision: http://reviews.llvm.org/D23619 llvm-svn: 279523
2016-08-23 23:39:03 +08:00
void Instruction::swapProfMetadata() {
MDNode *ProfileData = getMetadata(LLVMContext::MD_prof);
if (!ProfileData || ProfileData->getNumOperands() != 3 ||
!isa<MDString>(ProfileData->getOperand(0)))
return;
MDString *MDName = cast<MDString>(ProfileData->getOperand(0));
if (MDName->getString() != "branch_weights")
return;
// The first operand is the name. Fetch them backwards and build a new one.
Metadata *Ops[] = {ProfileData->getOperand(0), ProfileData->getOperand(2),
ProfileData->getOperand(1)};
setMetadata(LLVMContext::MD_prof,
MDNode::get(ProfileData->getContext(), Ops));
}
void Instruction::copyMetadata(const Instruction &SrcInst,
ArrayRef<unsigned> WL) {
if (!SrcInst.hasMetadata())
return;
DenseSet<unsigned> WLS;
for (unsigned M : WL)
WLS.insert(M);
// Otherwise, enumerate and copy over metadata from the old instruction to the
// new one.
SmallVector<std::pair<unsigned, MDNode *>, 4> TheMDs;
SrcInst.getAllMetadataOtherThanDebugLoc(TheMDs);
for (const auto &MD : TheMDs) {
if (WL.empty() || WLS.count(MD.first))
setMetadata(MD.first, MD.second);
}
if (WL.empty() || WLS.count(LLVMContext::MD_dbg))
setDebugLoc(SrcInst.getDebugLoc());
return;
}
Factor out redundancy from clone() implementations. llvm-svn: 85327
2009-10-28 06:16:29 +08:00
Instruction *Instruction::clone() const {
Devirtualize Instruction::clone_impl llvm-svn: 240588
2015-06-25 04:22:23 +08:00
Instruction *New = nullptr;
switch (getOpcode()) {
default:
llvm_unreachable("Unhandled Opcode.");
#define HANDLE_INST(num, opc, clas) \
case Instruction::opc: \
New = cast<clas>(this)->cloneImpl(); \
break;
#include "llvm/IR/Instruction.def"
#undef HANDLE_INST
}
Factor out redundancy from clone() implementations. llvm-svn: 85327
2009-10-28 06:16:29 +08:00
New->SubclassOptionalData = SubclassOptionalData;
[Profile] refactor meta data copying/swapping code Differential Revision: http://reviews.llvm.org/D23619 llvm-svn: 279523
2016-08-23 23:39:03 +08:00
New->copyMetadata(*this);
Factor out redundancy from clone() implementations. llvm-svn: 85327
2009-10-28 06:16:29 +08:00
return New;
}
Updates branch_weights annotation for call instructions during inlining. Summary: Inliner should update the branch_weights annotation to scale it to proper value. Reviewers: davidxl, eraman Reviewed By: eraman Subscribers: zzheng, llvm-commits Differential Revision: https://reviews.llvm.org/D30767 llvm-svn: 298270
2017-03-21 00:40:44 +08:00
void Instruction::updateProfWeight(uint64_t S, uint64_t T) {
auto *ProfileData = getMetadata(LLVMContext::MD_prof);
if (ProfileData == nullptr)
return;
auto *ProfDataName = dyn_cast<MDString>(ProfileData->getOperand(0));
Update VP prof metadata during inlining. Summary: r298270 added profile update logic for branch_weights. This patch implements profile update logic for VP prof metadata too. Reviewers: eraman, tejohnson, davidxl Reviewed By: eraman Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D32773 llvm-svn: 302209
2017-05-05 08:47:34 +08:00
if (!ProfDataName || (!ProfDataName->getString().equals("branch_weights") &&
!ProfDataName->getString().equals("VP")))
Updates branch_weights annotation for call instructions during inlining. Summary: Inliner should update the branch_weights annotation to scale it to proper value. Reviewers: davidxl, eraman Reviewed By: eraman Subscribers: zzheng, llvm-commits Differential Revision: https://reviews.llvm.org/D30767 llvm-svn: 298270
2017-03-21 00:40:44 +08:00
return;
MDBuilder MDB(getContext());
Update VP prof metadata during inlining. Summary: r298270 added profile update logic for branch_weights. This patch implements profile update logic for VP prof metadata too. Reviewers: eraman, tejohnson, davidxl Reviewed By: eraman Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D32773 llvm-svn: 302209
2017-05-05 08:47:34 +08:00
SmallVector<Metadata *, 3> Vals;
Vals.push_back(ProfileData->getOperand(0));
APInt APS(128, S), APT(128, T);
if (ProfDataName->getString().equals("branch_weights"))
for (unsigned i = 1; i < ProfileData->getNumOperands(); i++) {
// Using APInt::div may be expensive, but most cases should fit 64 bits.
APInt Val(128,
mdconst::dyn_extract<ConstantInt>(ProfileData->getOperand(i))
->getValue()
.getZExtValue());
Val *= APS;
Vals.push_back(MDB.createConstant(
ConstantInt::get(Type::getInt64Ty(getContext()),
Val.udiv(APT).getLimitedValue())));
}
else if (ProfDataName->getString().equals("VP"))
for (unsigned i = 1; i < ProfileData->getNumOperands(); i += 2) {
// The first value is the key of the value profile, which will not change.
Vals.push_back(ProfileData->getOperand(i));
// Using APInt::div may be expensive, but most cases should fit 64 bits.
APInt Val(128,
mdconst::dyn_extract<ConstantInt>(ProfileData->getOperand(i + 1))
->getValue()
.getZExtValue());
Val *= APS;
Vals.push_back(MDB.createConstant(
ConstantInt::get(Type::getInt64Ty(getContext()),
Val.udiv(APT).getLimitedValue())));
}
setMetadata(LLVMContext::MD_prof, MDNode::get(getContext(), Vals));
Updates branch_weights annotation for call instructions during inlining. Summary: Inliner should update the branch_weights annotation to scale it to proper value. Reviewers: davidxl, eraman Reviewed By: eraman Subscribers: zzheng, llvm-commits Differential Revision: https://reviews.llvm.org/D30767 llvm-svn: 298270
2017-03-21 00:40:44 +08:00
}
Set the prof weight correctly for call instructions in DeadArgumentElimination. Summary: In DeadArgumentElimination, the call instructions will be replaced. We also need to set the prof weights so that function inlining can find the correct profile. Reviewers: eraman Reviewed By: eraman Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D31143 llvm-svn: 298660
2017-03-24 07:26:00 +08:00
void Instruction::setProfWeight(uint64_t W) {
assert((isa<CallInst>(this) || isa<InvokeInst>(this)) &&
"Can only set weights for call and invoke instrucitons");
SmallVector<uint32_t, 1> Weights;
Weights.push_back(W);
MDBuilder MDB(getContext());
setMetadata(LLVMContext::MD_prof, MDB.createBranchWeights(Weights));
}