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

657 lines
23 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"
[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"
#include "llvm/IR/Module.h"
#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
}
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
// Out of line virtual method, so the vtable, etc has a home.
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();
}
[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
Module *Instruction::getModule() {
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
Function *Instruction::getFunction() { return getParent()->getParent(); }
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) {
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
MovePos->getParent()->getInstList().splice(
MovePos->getIterator(), 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();
}
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
/// Set or clear the unsafe-algebra flag on this instruction, which must be an
/// operator which supports this flag. See LangRef.html for the meaning of this
/// flag.
void Instruction::setHasUnsafeAlgebra(bool B) {
assert(isa<FPMathOperator>(this) && "setting fast-math flag on invalid op");
cast<FPMathOperator>(this)->setHasUnsafeAlgebra(B);
}
/// Set or clear the NoNaNs flag on this instruction, which must be an operator
/// which supports this flag. See LangRef.html for the meaning of this flag.
void Instruction::setHasNoNaNs(bool B) {
assert(isa<FPMathOperator>(this) && "setting fast-math flag on invalid op");
cast<FPMathOperator>(this)->setHasNoNaNs(B);
}
/// Set or clear the no-infs flag on this instruction, which must be an operator
/// which supports this flag. See LangRef.html for the meaning of this flag.
void Instruction::setHasNoInfs(bool B) {
assert(isa<FPMathOperator>(this) && "setting fast-math flag on invalid op");
cast<FPMathOperator>(this)->setHasNoInfs(B);
}
/// Set or clear the no-signed-zeros flag on this instruction, which must be an
/// operator which supports this flag. See LangRef.html for the meaning of this
/// flag.
void Instruction::setHasNoSignedZeros(bool B) {
assert(isa<FPMathOperator>(this) && "setting fast-math flag on invalid op");
cast<FPMathOperator>(this)->setHasNoSignedZeros(B);
}
/// Set or clear the allow-reciprocal flag on this instruction, which must be an
/// operator which supports this flag. See LangRef.html for the meaning of this
/// flag.
void Instruction::setHasAllowReciprocal(bool B) {
assert(isa<FPMathOperator>(this) && "setting fast-math flag on invalid op");
cast<FPMathOperator>(this)->setHasAllowReciprocal(B);
}
/// Convenience function for setting all the fast-math flags on this
/// instruction, which must be an operator which supports these flags. See
/// LangRef.html for the meaning of these flats.
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
/// Determine whether the unsafe-algebra flag is set.
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();
}
/// Determine whether the no-NaNs flag is set.
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();
}
/// Determine whether the no-infs flag is set.
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();
}
/// Determine whether the no-signed-zeros flag is set.
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();
}
/// Determine whether the allow-reciprocal flag is set.
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();
}
/// Convenience function for getting all the fast-math flags, which must be an
/// operator which supports these flags. See LangRef.html for the meaning of
typo llvm-svn: 217516
2014-09-11 00:58:40 +08:00
/// these flags.
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
/// Copy I's fast-math flags
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
}
[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::copyIRFlags(const Value *V) {
// Copy the wrapping flags.
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(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
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
/// Return true if both instructions have the same special state This must be
/// 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() &&
LI->getSynchScope() == cast<LoadInst>(I2)->getSynchScope();
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() &&
SI->getSynchScope() == cast<StoreInst>(I2)->getSynchScope();
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() &&
FI->getSynchScope() == cast<FenceInst>(I2)->getSynchScope();
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() &&
CXI->getSynchScope() == cast<AtomicCmpXchgInst>(I2)->getSynchScope();
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() &&
RMWI->getSynchScope() == cast<AtomicRMWInst>(I2)->getSynchScope();
return true;
}
Add method llvm-svn: 18368
2004-11-30 10:51:53 +08:00
/// isIdenticalTo - Return true if the specified instruction is exactly
/// identical to the current one. This means that all operands match and any
/// extra information (e.g. load is volatile) agree.
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;
}
This should use isIndenticalToWhenDefined. llvm-svn: 80039
2009-08-26 06:24:20 +08:00
/// isIdenticalToWhenDefined - This is like isIdenticalTo, except that it
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
/// ignores the SubclassOptionalData flags, which specify conditions
/// under which the instruction's result is undefined.
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
/// isUsedOutsideOfBlock - Return true if there are any uses of I outside of the
/// specified block. Note that PHI nodes are considered to evaluate their
/// operands in the corresponding predecessor block.
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
/// mayReadFromMemory - Return true if this instruction may read memory.
///
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
/// mayWriteToMemory - Return true if this instruction may modify memory.
///
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
}
}
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
}
New isAssociative/isCommutative inspection methods, graciously contributed by Casey Carter. llvm-svn: 4459
2002-10-31 12:14:01 +08:00
/// isAssociative - Return true if the instruction is associative:
///
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
/// Associative operators satisfy: x op (y op z) === (x op y) op z
New isAssociative/isCommutative inspection methods, graciously contributed by Casey Carter. llvm-svn: 4459
2002-10-31 12:14:01 +08:00
///
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
/// In LLVM, the Add, Mul, And, Or, and Xor operators are associative.
New isAssociative/isCommutative inspection methods, graciously contributed by Casey Carter. llvm-svn: 4459
2002-10-31 12:14:01 +08:00
///
There is no need for isAssociative to take the type as an argument anymore. llvm-svn: 122242
2010-12-20 21:10:23 +08:00
bool Instruction::isAssociative(unsigned Opcode) {
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
return Opcode == And || Opcode == Or || Opcode == Xor ||
Opcode == Add || Opcode == Mul;
New isAssociative/isCommutative inspection methods, graciously contributed by Casey Carter. llvm-svn: 4459
2002-10-31 12:14:01 +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;
}
}
New isAssociative/isCommutative inspection methods, graciously contributed by Casey Carter. llvm-svn: 4459
2002-10-31 12:14:01 +08:00
/// isCommutative - Return true if the instruction is commutative:
///
Fix spelling/grammar. llvm-svn: 9023
2003-10-11 01:54:14 +08:00
/// Commutative operators satisfy: (x op y) === (y op x)
New isAssociative/isCommutative inspection methods, graciously contributed by Casey Carter. llvm-svn: 4459
2002-10-31 12:14:01 +08:00
///
/// In LLVM, these are the associative operators, plus SetEQ and SetNE, when
/// applied to any type.
///
bool Instruction::isCommutative(unsigned op) {
switch (op) {
case 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:
New isAssociative/isCommutative inspection methods, graciously contributed by Casey Carter. llvm-svn: 4459
2002-10-31 12:14:01 +08:00
case 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:
Remove trailing whitespace llvm-svn: 21427
2005-04-22 07:48:37 +08:00
case And:
New isAssociative/isCommutative inspection methods, graciously contributed by Casey Carter. llvm-svn: 4459
2002-10-31 12:14:01 +08:00
case Or:
case Xor:
return true;
default:
return false;
}
}
Added function to determine if an Instruction may trap. llvm-svn: 7442
2003-07-31 12:05:50 +08:00
Now that Reassociate's LinearizeExprTree can look through arbitrary expression topologies, it is quite possible for a leaf node to have huge multiplicity, for example: x0 = x*x, x1 = x0*x0, x2 = x1*x1, ... rapidly gives a value which is x raised to a vast power (the multiplicity, or weight, of x). This patch fixes the computation of weights by correctly computing them no matter how big they are, rather than just overflowing and getting a wrong value. It turns out that the weight for a value never needs more bits to represent than the value itself, so it is enough to represent weights as APInts of the same bitwidth and do the right overflow-avoiding dance steps when computing weights. As a side-effect it reduces the number of multiplies needed in some cases of large powers. While there, in view of external uses (eg by the vectorizer) I made LinearizeExprTree static, pushing the rank computation out into users. This is progress towards fixing PR13021. llvm-svn: 158358
2012-06-12 22:33:56 +08:00
/// isIdempotent - Return true if the instruction is idempotent:
///
/// Idempotent operators satisfy: x op x === x
///
/// In LLVM, the And and Or operators are idempotent.
///
bool Instruction::isIdempotent(unsigned Opcode) {
return Opcode == And || Opcode == Or;
}
/// isNilpotent - Return true if the instruction is nilpotent:
///
/// Nilpotent operators satisfy: x op x === Id,
///
/// where Id is the identity for the operator, i.e. a constant such that
/// x op Id === x and Id op x === x for all x.
///
/// In LLVM, the Xor operator is nilpotent.
///
bool Instruction::isNilpotent(unsigned Opcode) {
return Opcode == Xor;
}
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");
}
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;
remove some unneeded Metadata interfaces. llvm-svn: 92252
2009-12-29 15:44:16 +08:00
if (!hasMetadata())
return New;
Remove trailing whitespace llvm-svn: 168103
2012-11-16 06:34:00 +08:00
remove some unneeded Metadata interfaces. llvm-svn: 92252
2009-12-29 15:44:16 +08:00
// Otherwise, enumerate and copy over metadata from the old instruction to the
// new one.
Revert "IR: MDNode => Value" Instead, we're going to separate metadata from the Value hierarchy. See PR21532. This reverts commit r221375. This reverts commit r221373. This reverts commit r221359. This reverts commit r221167. This reverts commit r221027. This reverts commit r221024. This reverts commit r221023. This reverts commit r220995. This reverts commit r220994. llvm-svn: 221711
2014-11-12 05:30:22 +08:00
SmallVector<std::pair<unsigned, MDNode *>, 4> TheMDs;
manually copy debugloc over to a new instruction in clone() instead of calling getAllMetadata(). This is semantically identical, but doing it this way avoids unpacking the DebugLoc. llvm-svn: 135173
2011-07-15 02:57:51 +08:00
getAllMetadataOtherThanDebugLoc(TheMDs);
[C++11] Modernize the IR library a bit. No functionality change. llvm-svn: 203465
2014-03-10 23:03:06 +08:00
for (const auto &MD : TheMDs)
New->setMetadata(MD.first, MD.second);
Remove trailing whitespace llvm-svn: 168103
2012-11-16 06:34:00 +08:00
manually copy debugloc over to a new instruction in clone() instead of calling getAllMetadata(). This is semantically identical, but doing it this way avoids unpacking the DebugLoc. llvm-svn: 135173
2011-07-15 02:57:51 +08:00
New->setDebugLoc(getDebugLoc());
Factor out redundancy from clone() implementations. llvm-svn: 85327
2009-10-28 06:16:29 +08:00
return New;
}