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

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

793 lines
27 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
//
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
2019-01-19 16:50:56 +08:00
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
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"
[IR] Introduce helpers to skip debug instructions (NFC) This patch introduces two helpers to make it easier to ignore debug intrinsics: - Instruction::getNextNonDebugInstruction() This is just like Instruction::getNextNode(), except that it skips debug info. - skipDebugInfo(BasicBlock::iterator) A free function which advances a BasicBlock iterator past any debug info. This is a no-op when the iterator already points to a non-debug instruction. Part of: llvm.org/PR37728 Related to: https://reviews.llvm.org/D47874 Differential Revision: https://reviews.llvm.org/D48305 llvm-svn: 335083
2018-06-20 07:42:17 +08:00
#include "llvm/IR/IntrinsicInst.h"
Sort the remaining #include lines in include/... and lib/.... I did this a long time ago with a janky python script, but now clang-format has built-in support for this. I fed clang-format every line with a #include and let it re-sort things according to the precise LLVM rules for include ordering baked into clang-format these days. I've reverted a number of files where the results of sorting includes isn't healthy. Either places where we have legacy code relying on particular include ordering (where possible, I'll fix these separately) or where we have particular formatting around #include lines that I didn't want to disturb in this patch. This patch is *entirely* mechanical. If you get merge conflicts or anything, just ignore the changes in this patch and run clang-format over your #include lines in the files. Sorry for any noise here, but it is important to keep these things stable. I was seeing an increasing number of patches with irrelevant re-ordering of #include lines because clang-format was used. This patch at least isolates that churn, makes it easy to skip when resolving conflicts, and gets us to a clean baseline (again). llvm-svn: 304787
2017-06-06 19:49:48 +08:00
#include "llvm/ADT/DenseSet.h"
Move all of the header files which are involved in modelling the LLVM IR into their new header subdirectory: include/llvm/IR. This matches the directory structure of lib, and begins to correct a long standing point of file layout clutter in LLVM. There are still more header files to move here, but I wanted to handle them in separate commits to make tracking what files make sense at each layer easier. The only really questionable files here are the target intrinsic tablegen files. But that's a battle I'd rather not fight today. I've updated both CMake and Makefile build systems (I think, and my tests think, but I may have missed something). I've also re-sorted the includes throughout the project. I'll be committing updates to Clang, DragonEgg, and Polly momentarily. llvm-svn: 171366
2013-01-02 19:36:10 +08:00
#include "llvm/IR/Constants.h"
#include "llvm/IR/Instructions.h"
Updates branch_weights annotation for call instructions during inlining. Summary: Inliner should update the branch_weights annotation to scale it to proper value. Reviewers: davidxl, eraman Reviewed By: eraman Subscribers: zzheng, llvm-commits Differential Revision: https://reviews.llvm.org/D30767 llvm-svn: 298270
2017-03-21 00:40:44 +08:00
#include "llvm/IR/MDBuilder.h"
Move all of the header files which are involved in modelling the LLVM IR into their new header subdirectory: include/llvm/IR. This matches the directory structure of lib, and begins to correct a long standing point of file layout clutter in LLVM. There are still more header files to move here, but I wanted to handle them in separate commits to make tracking what files make sense at each layer easier. The only really questionable files here are the target intrinsic tablegen files. But that's a battle I'd rather not fight today. I've updated both CMake and Makefile build systems (I think, and my tests think, but I may have missed something). I've also re-sorted the includes throughout the project. I'll be committing updates to Clang, DragonEgg, and Polly momentarily. llvm-svn: 171366
2013-01-02 19:36:10 +08:00
#include "llvm/IR/Operator.h"
#include "llvm/IR/Type.h"
* Finegrainify namespacification * Add new constructors to allow insertion of terminator instructions at the end of basic blocks. * Move a ReturnInst method out-of-line, so that the vtable and type info don't need to be emitted to every translation unit that uses the class. llvm-svn: 10107
2003-11-21 01:45:12 +08:00
using namespace llvm;
Put all LLVM code into the llvm namespace, as per bug 109. llvm-svn: 9903
2003-11-12 06:41:34 +08:00
land David Blaikie's patch to de-constify Type, with a few tweaks. llvm-svn: 135375
2011-07-18 12:54:35 +08:00
Instruction::Instruction(Type *ty, unsigned it, Use *Ops, unsigned NumOps,
Refactor the setName stuff, moving it down the inheritance hierarchy, to solve a crash in -instcombine -debug that was hit while investigating PR1217 llvm-svn: 34544
2007-02-24 08:55:48 +08:00
Instruction *InsertBefore)
[C++11] More 'nullptr' conversion or in some cases just using a boolean check instead of comparing to nullptr. llvm-svn: 205831
2014-04-09 14:08:46 +08:00
: User(ty, Value::InstructionVal + it, Ops, NumOps), Parent(nullptr) {
Add capability to insert an instruction into a basic block immediately after it is created, as part of the ctor call. Eliminate the GenericBinaryInst class llvm-svn: 3653
2002-09-10 23:45:53 +08:00
// If requested, insert this instruction into a basic block...
if (InsertBefore) {
De-duplicate common expression, NFC. llvm-svn: 239736
2015-06-16 01:03:35 +08:00
BasicBlock *BB = InsertBefore->getParent();
assert(BB && "Instruction to insert before is not in a basic block!");
IR: Remove implicit iterator conversions from lib/IR, NFC Stop converting implicitly between iterators and pointers/references in lib/IR. For convenience, I've added a `getIterator()` accessor to `ilist_node` so that callers don't need to know how to spell the iterator class (i.e., they can use `X.getIterator()` instead of `Function::iterator(X)`). I'll eventually disallow these implicit conversions entirely, but there's a lot of code, so it doesn't make sense to do it all in one patch. One library or so at a time. Why? To root out cases of `getNextNode()` and `getPrevNode()` being used in iterator logic. The design of `ilist` makes that invalid when the current node could be at the back of the list, but it happens to "work" right now because of a bug where those functions never return `nullptr` if you're using a half-node sentinel. Before I can fix the function, I have to remove uses of it that rely on it misbehaving. (Maybe the function should just be deleted anyway? But I don't want deleting it -- potentially a huge project -- to block fixing ilist/iplist.) llvm-svn: 249782
2015-10-09 07:49:46 +08:00
BB->getInstList().insert(InsertBefore->getIterator(), this);
Add capability to insert an instruction into a basic block immediately after it is created, as part of the ctor call. Eliminate the GenericBinaryInst class llvm-svn: 3653
2002-09-10 23:45:53 +08:00
}
Initial revision llvm-svn: 2
2001-06-07 04:29:01 +08:00
}
land David Blaikie's patch to de-constify Type, with a few tweaks. llvm-svn: 135375
2011-07-18 12:54:35 +08:00
Instruction::Instruction(Type *ty, unsigned it, Use *Ops, unsigned NumOps,
Refactor the setName stuff, moving it down the inheritance hierarchy, to solve a crash in -instcombine -debug that was hit while investigating PR1217 llvm-svn: 34544
2007-02-24 08:55:48 +08:00
BasicBlock *InsertAtEnd)
[C++11] More 'nullptr' conversion or in some cases just using a boolean check instead of comparing to nullptr. llvm-svn: 205831
2014-04-09 14:08:46 +08:00
: User(ty, Value::InstructionVal + it, Ops, NumOps), Parent(nullptr) {
Refactor common initialization code in private init() functions. This is a first step in supplying append to basic block constructors for all instruction types. llvm-svn: 13793
2004-05-27 05:41:09 +08:00
// append this instruction into the basic block
assert(InsertAtEnd && "Basic block to append to may not be NULL!");
InsertAtEnd->getInstList().push_back(this);
Switch UnaryOperators to default to passing names up by const char* when possible. This speeds up bcreading by 1.5%. llvm-svn: 34233
2007-02-13 15:54:42 +08:00
}
Reverting dtor devirtualization patch. _sabre_: it has a major problem: by the time ~Value is run, all of the "parts" of the derived classes have been destroyed _sabre_: the vtable lives to fight another day llvm-svn: 44760
2007-12-10 10:14:30 +08:00
Instruction::~Instruction() {
[C++11] More 'nullptr' conversion. In some cases just using a boolean check instead of comparing to nullptr. llvm-svn: 206252
2014-04-15 14:32:26 +08:00
assert(!Parent && "Instruction still linked in the program!");
[Instruction] Set metadata uses to undef on deletion Summary: Replace any extant metadata uses of a dying instruction with undef to preserve debug info accuracy. Some alternatives include: - Treat Instruction like any other Value, and point its extant metadata uses to an empty ValueAsMetadata node. This makes extant dbg.value uses trivially dead (i.e. fair game for deletion in many passes), leading to stale dbg.values being in effect for too long. - Call salvageDebugInfoOrMarkUndef. Not needed to make instruction removal correct. OTOH results in wasted work in some common cases (e.g. when all instructions in a BasicBlock are deleted). This came up while discussing some basic cases in https://reviews.llvm.org/D80052. Reviewers: jmorse, TWeaver, aprantl, dexonsmith, jdoerfert Subscribers: jholewinski, qcolombet, hiraditya, jfb, sstefan1, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D80264
2020-05-20 09:03:22 +08:00
// Replace any extant metadata uses of this instruction with undef to
// preserve debug info accuracy. Some alternatives include:
// - Treat Instruction like any other Value, and point its extant metadata
// uses to an empty ValueAsMetadata node. This makes extant dbg.value uses
// trivially dead (i.e. fair game for deletion in many passes), leading to
// stale dbg.values being in effect for too long.
// - Call salvageDebugInfoOrMarkUndef. Not needed to make instruction removal
// correct. OTOH results in wasted work in some common cases (e.g. when all
// instructions in a BasicBlock are deleted).
if (isUsedByMetadata())
ValueAsMetadata::handleRAUW(this, UndefValue::get(getType()));
Rename removeAllMetadata to clearMetadataHashEntries and simplify it to just do the things that need to be done when an instruction is deleted. llvm-svn: 108948
2010-07-21 06:25:04 +08:00
if (hasMetadataHashEntry())
clearMetadataHashEntries();
Add some out-of-line virtual dtors so that the class has a "home", preventing vtables for (e.g.) Instruction from being emitted into every .o file. llvm-svn: 28898
2006-06-22 00:53:47 +08:00
}
Move code out of header files into .cpp files to make future changes easier llvm-svn: 3605
2002-09-07 05:33:15 +08:00
void Instruction::setParent(BasicBlock *P) {
Parent = P;
}
Remove getDataLayout() from Instruction/GlobalValue/BasicBlock/Function Summary: This does not conceptually belongs here. Instead provide a shortcut getModule() that provides access to the DataLayout. Reviewers: chandlerc, echristo Reviewed By: echristo Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D8027 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 231147
2015-03-04 06:01:13 +08:00
const Module *Instruction::getModule() const {
return getParent()->getModule();
}
Add Instruction::getFunction; NFC Will be used in a upcoming patch. llvm-svn: 254975
2015-12-08 08:13:12 +08:00
const Function *Instruction::getFunction() const {
return getParent()->getParent();
}
[PlaceSafepoints] Cleanup InsertSafepointPoll function While working on another change, I noticed that the naming in this function was mildly deceptive. While fixing that, I took the oppurtunity to modernize some of the code. NFC intended. llvm-svn: 238252
2015-05-27 05:03:23 +08:00
Implement remove/eraseFromParent methods llvm-svn: 16922
2004-10-12 06:21:39 +08:00
void Instruction::removeFromParent() {
IR: Remove implicit iterator conversions from lib/IR, NFC Stop converting implicitly between iterators and pointers/references in lib/IR. For convenience, I've added a `getIterator()` accessor to `ilist_node` so that callers don't need to know how to spell the iterator class (i.e., they can use `X.getIterator()` instead of `Function::iterator(X)`). I'll eventually disallow these implicit conversions entirely, but there's a lot of code, so it doesn't make sense to do it all in one patch. One library or so at a time. Why? To root out cases of `getNextNode()` and `getPrevNode()` being used in iterator logic. The design of `ilist` makes that invalid when the current node could be at the back of the list, but it happens to "work" right now because of a bug where those functions never return `nullptr` if you're using a half-node sentinel. Before I can fix the function, I have to remove uses of it that rely on it misbehaving. (Maybe the function should just be deleted anyway? But I don't want deleting it -- potentially a huge project -- to block fixing ilist/iplist.) llvm-svn: 249782
2015-10-09 07:49:46 +08:00
getParent()->getInstList().remove(getIterator());
Implement remove/eraseFromParent methods llvm-svn: 16922
2004-10-12 06:21:39 +08:00
}
Return iterator from Instruction::eraseFromParent. Summary: This is necessary in order to make removal while using reverse iterators work. (See http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-March/084122.html) Updates to other eraseFromParent's to come in later patches. Reviewers: chandlerc Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D8783 llvm-svn: 233869
2015-04-02 08:03:07 +08:00
iplist<Instruction>::iterator Instruction::eraseFromParent() {
IR: Remove implicit iterator conversions from lib/IR, NFC Stop converting implicitly between iterators and pointers/references in lib/IR. For convenience, I've added a `getIterator()` accessor to `ilist_node` so that callers don't need to know how to spell the iterator class (i.e., they can use `X.getIterator()` instead of `Function::iterator(X)`). I'll eventually disallow these implicit conversions entirely, but there's a lot of code, so it doesn't make sense to do it all in one patch. One library or so at a time. Why? To root out cases of `getNextNode()` and `getPrevNode()` being used in iterator logic. The design of `ilist` makes that invalid when the current node could be at the back of the list, but it happens to "work" right now because of a bug where those functions never return `nullptr` if you're using a half-node sentinel. Before I can fix the function, I have to remove uses of it that rely on it misbehaving. (Maybe the function should just be deleted anyway? But I don't want deleting it -- potentially a huge project -- to block fixing ilist/iplist.) llvm-svn: 249782
2015-10-09 07:49:46 +08:00
return getParent()->getInstList().erase(getIterator());
Implement remove/eraseFromParent methods llvm-svn: 16922
2004-10-12 06:21:39 +08:00
}
Create a static version of Instruction::getOpcodeName(opCode) that can be invoked with only an opcode (i.e., without an instruction). Move all opCode->opCodeName translations there. llvm-svn: 2900
2002-07-15 07:09:40 +08:00
fix typos; NFC llvm-svn: 256881
2016-01-06 08:18:29 +08:00
/// Insert an unlinked instruction into a basic block immediately before the
/// specified instruction.
Add an insertBefore method for attaching previously unattached instructions, such as those created by clone(), to a basic block. llvm-svn: 52424
2008-06-18 02:29:27 +08:00
void Instruction::insertBefore(Instruction *InsertPos) {
IR: Remove implicit iterator conversions from lib/IR, NFC Stop converting implicitly between iterators and pointers/references in lib/IR. For convenience, I've added a `getIterator()` accessor to `ilist_node` so that callers don't need to know how to spell the iterator class (i.e., they can use `X.getIterator()` instead of `Function::iterator(X)`). I'll eventually disallow these implicit conversions entirely, but there's a lot of code, so it doesn't make sense to do it all in one patch. One library or so at a time. Why? To root out cases of `getNextNode()` and `getPrevNode()` being used in iterator logic. The design of `ilist` makes that invalid when the current node could be at the back of the list, but it happens to "work" right now because of a bug where those functions never return `nullptr` if you're using a half-node sentinel. Before I can fix the function, I have to remove uses of it that rely on it misbehaving. (Maybe the function should just be deleted anyway? But I don't want deleting it -- potentially a huge project -- to block fixing ilist/iplist.) llvm-svn: 249782
2015-10-09 07:49:46 +08:00
InsertPos->getParent()->getInstList().insert(InsertPos->getIterator(), this);
Add an insertBefore method for attaching previously unattached instructions, such as those created by clone(), to a basic block. llvm-svn: 52424
2008-06-18 02:29:27 +08:00
}
fix typos; NFC llvm-svn: 256881
2016-01-06 08:18:29 +08:00
/// Insert an unlinked instruction into a basic block immediately after the
/// specified instruction.
add a new insertAfter method, patch by Tom Jablin! llvm-svn: 62158
2009-01-13 15:43:51 +08:00
void Instruction::insertAfter(Instruction *InsertPos) {
IR: Remove implicit iterator conversions from lib/IR, NFC Stop converting implicitly between iterators and pointers/references in lib/IR. For convenience, I've added a `getIterator()` accessor to `ilist_node` so that callers don't need to know how to spell the iterator class (i.e., they can use `X.getIterator()` instead of `Function::iterator(X)`). I'll eventually disallow these implicit conversions entirely, but there's a lot of code, so it doesn't make sense to do it all in one patch. One library or so at a time. Why? To root out cases of `getNextNode()` and `getPrevNode()` being used in iterator logic. The design of `ilist` makes that invalid when the current node could be at the back of the list, but it happens to "work" right now because of a bug where those functions never return `nullptr` if you're using a half-node sentinel. Before I can fix the function, I have to remove uses of it that rely on it misbehaving. (Maybe the function should just be deleted anyway? But I don't want deleting it -- potentially a huge project -- to block fixing ilist/iplist.) llvm-svn: 249782
2015-10-09 07:49:46 +08:00
InsertPos->getParent()->getInstList().insertAfter(InsertPos->getIterator(),
this);
add a new insertAfter method, patch by Tom Jablin! llvm-svn: 62158
2009-01-13 15:43:51 +08:00
}
fix typos; NFC llvm-svn: 256881
2016-01-06 08:18:29 +08:00
/// Unlink this instruction from its current basic block and insert it into the
/// basic block that MovePos lives in, right before MovePos.
add new helper function llvm-svn: 22698
2005-08-08 13:21:50 +08:00
void Instruction::moveBefore(Instruction *MovePos) {
Scalar: Avoid dereferencing end() in IndVarSimplify IndVarSimplify::sinkUnusedInvariants calls BasicBlock::getFirstInsertionPt on the ExitBlock and moves instructions before it. This can return end(), so it's not safe to dereference. Add an iterator-based overload to Instruction::moveBefore to avoid the UB. llvm-svn: 278886
2016-08-17 09:54:41 +08:00
moveBefore(*MovePos->getParent(), MovePos->getIterator());
}
[Instruction] add moveAfter() convenience function; NFCI As suggested in D37121, here's a wrapper for removeFromParent() + insertAfter(), but implemented using moveBefore() for symmetry/efficiency. Differential Revision: https://reviews.llvm.org/D37239 llvm-svn: 312001
2017-08-29 22:07:48 +08:00
void Instruction::moveAfter(Instruction *MovePos) {
moveBefore(*MovePos->getParent(), ++MovePos->getIterator());
}
Scalar: Avoid dereferencing end() in IndVarSimplify IndVarSimplify::sinkUnusedInvariants calls BasicBlock::getFirstInsertionPt on the ExitBlock and moves instructions before it. This can return end(), so it's not safe to dereference. Add an iterator-based overload to Instruction::moveBefore to avoid the UB. llvm-svn: 278886
2016-08-17 09:54:41 +08:00
void Instruction::moveBefore(BasicBlock &BB,
SymbolTableList<Instruction>::iterator I) {
assert(I == BB.end() || I->getParent() == &BB);
BB.getInstList().splice(I, getParent()->getInstList(), getIterator());
add new helper function llvm-svn: 22698
2005-08-08 13:21:50 +08:00
}
[IR] Lazily number instructions for local dominance queries Essentially, fold OrderedBasicBlock into BasicBlock, and make it auto-invalidate the instruction ordering when new instructions are added. Notably, we don't need to invalidate it when removing instructions, which is helpful when a pass mostly delete dead instructions rather than transforming them. The downside is that Instruction grows from 56 bytes to 64 bytes. The resulting LLVM code is substantially simpler and automatically handles invalidation, which makes me think that this is the right speed and size tradeoff. The important change is in SymbolTableTraitsImpl.h, where the numbering is invalidated. Everything else should be straightforward. We probably want to implement a fancier re-numbering scheme so that local updates don't invalidate the ordering, but I plan for that to be future work, maybe for someone else. Reviewed By: lattner, vsk, fhahn, dexonsmith Differential Revision: https://reviews.llvm.org/D51664
2020-02-19 06:33:54 +08:00
bool Instruction::comesBefore(const Instruction *Other) const {
assert(Parent && Other->Parent &&
"instructions without BB parents have no order");
assert(Parent == Other->Parent && "cross-BB instruction order comparison");
if (!Parent->isInstrOrderValid())
Parent->renumberInstructions();
return Order < Other->Order;
}
[EarlyCSE] Take the intersection of flags on instructions EarlyCSE had inconsistent behavior with regards to flag'd instructions: - In some cases, it would pessimize if the available instruction had different flags by not performing CSE. - In other cases, it would miscompile if it replaced an instruction which had no flags with an instruction which has flags. Fix this by being more consistent with our flag handling by utilizing andIRFlags. llvm-svn: 267111
2016-04-22 14:37:45 +08:00
void Instruction::setHasNoUnsignedWrap(bool b) {
cast<OverflowingBinaryOperator>(this)->setHasNoUnsignedWrap(b);
}
void Instruction::setHasNoSignedWrap(bool b) {
cast<OverflowingBinaryOperator>(this)->setHasNoSignedWrap(b);
}
void Instruction::setIsExact(bool b) {
cast<PossiblyExactOperator>(this)->setIsExact(b);
}
bool Instruction::hasNoUnsignedWrap() const {
return cast<OverflowingBinaryOperator>(this)->hasNoUnsignedWrap();
}
bool Instruction::hasNoSignedWrap() const {
return cast<OverflowingBinaryOperator>(this)->hasNoSignedWrap();
}
[IR] Add a Instruction::dropPoisonGeneratingFlags helper Summary: The helper will be used in a later change. This change itself is NFC since the only user of this new function is its unit test. Reviewers: majnemer, efriedma Reviewed By: efriedma Subscribers: efriedma, mcrosier, llvm-commits Differential Revision: https://reviews.llvm.org/D30184 llvm-svn: 296035
2017-02-24 06:50:52 +08:00
void Instruction::dropPoisonGeneratingFlags() {
switch (getOpcode()) {
case Instruction::Add:
case Instruction::Sub:
case Instruction::Mul:
case Instruction::Shl:
cast<OverflowingBinaryOperator>(this)->setHasNoUnsignedWrap(false);
cast<OverflowingBinaryOperator>(this)->setHasNoSignedWrap(false);
break;
case Instruction::UDiv:
case Instruction::SDiv:
case Instruction::AShr:
case Instruction::LShr:
cast<PossiblyExactOperator>(this)->setIsExact(false);
break;
case Instruction::GetElementPtr:
cast<GetElementPtrInst>(this)->setIsInBounds(false);
break;
}
Add a transform pass to make the executable semantics of poison explicit in the IR Implements a transform pass which instruments IR such that poison semantics are made explicit. That is, it provides a (possibly partial) executable semantics for every instruction w.r.t. poison as specified in the LLVM LangRef. There are obvious parallels to the sanitizer tools, but this pass is focused purely on the semantics of LLVM IR, not any particular source language. The target audience for this tool is developers working on or targetting LLVM from a frontend. The idea is to be able to take arbitrary IR (with the assumption of known inputs), and evaluate it concretely after having made poison semantics explicit to detect cases where either a) the original code executes UB, or b) a transform pass introduces UB which didn't exist in the original program. At the moment, this is mostly the framework and still needs to be fleshed out. By reusing existing code we have decent coverage, but there's a lot of cases not yet handled. What's here is good enough to handle interesting cases though; for instance, one of the recent LFTR bugs involved UB being triggered by integer induction variables with nsw/nuw flags would be reported by the current code. (See comment in PoisonChecking.cpp for full explanation and context) Differential Revision: https://reviews.llvm.org/D64215 llvm-svn: 365536
2019-07-10 02:49:29 +08:00
// TODO: FastMathFlags!
[IR] Add a Instruction::dropPoisonGeneratingFlags helper Summary: The helper will be used in a later change. This change itself is NFC since the only user of this new function is its unit test. Reviewers: majnemer, efriedma Reviewed By: efriedma Subscribers: efriedma, mcrosier, llvm-commits Differential Revision: https://reviews.llvm.org/D30184 llvm-svn: 296035
2017-02-24 06:50:52 +08:00
}
Add a transform pass to make the executable semantics of poison explicit in the IR Implements a transform pass which instruments IR such that poison semantics are made explicit. That is, it provides a (possibly partial) executable semantics for every instruction w.r.t. poison as specified in the LLVM LangRef. There are obvious parallels to the sanitizer tools, but this pass is focused purely on the semantics of LLVM IR, not any particular source language. The target audience for this tool is developers working on or targetting LLVM from a frontend. The idea is to be able to take arbitrary IR (with the assumption of known inputs), and evaluate it concretely after having made poison semantics explicit to detect cases where either a) the original code executes UB, or b) a transform pass introduces UB which didn't exist in the original program. At the moment, this is mostly the framework and still needs to be fleshed out. By reusing existing code we have decent coverage, but there's a lot of cases not yet handled. What's here is good enough to handle interesting cases though; for instance, one of the recent LFTR bugs involved UB being triggered by integer induction variables with nsw/nuw flags would be reported by the current code. (See comment in PoisonChecking.cpp for full explanation and context) Differential Revision: https://reviews.llvm.org/D64215 llvm-svn: 365536
2019-07-10 02:49:29 +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
bool Instruction::isExact() const {
return cast<PossiblyExactOperator>(this)->isExact();
}
[IR] redefine 'UnsafeAlgebra' / 'reassoc' fast-math-flags and add 'trans' fast-math-flag As discussed on llvm-dev: http://lists.llvm.org/pipermail/llvm-dev/2016-November/107104.html and again more recently: http://lists.llvm.org/pipermail/llvm-dev/2017-October/118118.html ...this is a step in cleaning up our fast-math-flags implementation in IR to better match the capabilities of both clang's user-visible flags and the backend's flags for SDNode. As proposed in the above threads, we're replacing the 'UnsafeAlgebra' bit (which had the 'umbrella' meaning that all flags are set) with a new bit that only applies to algebraic reassociation - 'AllowReassoc'. We're also adding a bit to allow approximations for library functions called 'ApproxFunc' (this was initially proposed as 'libm' or similar). ...and we're out of bits. 7 bits ought to be enough for anyone, right? :) FWIW, I did look at getting this out of SubclassOptionalData via SubclassData (spacious 16-bits), but that's apparently already used for other purposes. Also, I don't think we can just add a field to FPMathOperator because Operator is not intended to be instantiated. We'll defer movement of FMF to another day. We keep the 'fast' keyword. I thought about removing that, but seeing IR like this: %f.fast = fadd reassoc nnan ninf nsz arcp contract afn float %op1, %op2 ...made me think we want to keep the shortcut synonym. Finally, this change is binary incompatible with existing IR as seen in the compatibility tests. This statement: "Newer releases can ignore features from older releases, but they cannot miscompile them. For example, if nsw is ever replaced with something else, dropping it would be a valid way to upgrade the IR." ( http://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility ) ...provides the flexibility we want to make this change without requiring a new IR version. Ie, we're not loosening the FP strictness of existing IR. At worst, we will fail to optimize some previously 'fast' code because it's no longer recognized as 'fast'. This should get fixed as we audit/squash all of the uses of 'isFast()'. Note: an inter-dependent clang commit to use the new API name should closely follow commit. Differential Revision: https://reviews.llvm.org/D39304 llvm-svn: 317488
2017-11-07 00:27:15 +08:00
void Instruction::setFast(bool B) {
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
assert(isa<FPMathOperator>(this) && "setting fast-math flag on invalid op");
[IR] redefine 'UnsafeAlgebra' / 'reassoc' fast-math-flags and add 'trans' fast-math-flag As discussed on llvm-dev: http://lists.llvm.org/pipermail/llvm-dev/2016-November/107104.html and again more recently: http://lists.llvm.org/pipermail/llvm-dev/2017-October/118118.html ...this is a step in cleaning up our fast-math-flags implementation in IR to better match the capabilities of both clang's user-visible flags and the backend's flags for SDNode. As proposed in the above threads, we're replacing the 'UnsafeAlgebra' bit (which had the 'umbrella' meaning that all flags are set) with a new bit that only applies to algebraic reassociation - 'AllowReassoc'. We're also adding a bit to allow approximations for library functions called 'ApproxFunc' (this was initially proposed as 'libm' or similar). ...and we're out of bits. 7 bits ought to be enough for anyone, right? :) FWIW, I did look at getting this out of SubclassOptionalData via SubclassData (spacious 16-bits), but that's apparently already used for other purposes. Also, I don't think we can just add a field to FPMathOperator because Operator is not intended to be instantiated. We'll defer movement of FMF to another day. We keep the 'fast' keyword. I thought about removing that, but seeing IR like this: %f.fast = fadd reassoc nnan ninf nsz arcp contract afn float %op1, %op2 ...made me think we want to keep the shortcut synonym. Finally, this change is binary incompatible with existing IR as seen in the compatibility tests. This statement: "Newer releases can ignore features from older releases, but they cannot miscompile them. For example, if nsw is ever replaced with something else, dropping it would be a valid way to upgrade the IR." ( http://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility ) ...provides the flexibility we want to make this change without requiring a new IR version. Ie, we're not loosening the FP strictness of existing IR. At worst, we will fail to optimize some previously 'fast' code because it's no longer recognized as 'fast'. This should get fixed as we audit/squash all of the uses of 'isFast()'. Note: an inter-dependent clang commit to use the new API name should closely follow commit. Differential Revision: https://reviews.llvm.org/D39304 llvm-svn: 317488
2017-11-07 00:27:15 +08:00
cast<FPMathOperator>(this)->setFast(B);
}
void Instruction::setHasAllowReassoc(bool B) {
assert(isa<FPMathOperator>(this) && "setting fast-math flag on invalid op");
cast<FPMathOperator>(this)->setHasAllowReassoc(B);
Fast-math interfaces for Instructions Add in getter/setter methods for Instructions, allowing them to be the interface to FPMathOperator similarly to now NUS/NSW is handled. llvm-svn: 168642
2012-11-27 08:41:22 +08:00
}
void Instruction::setHasNoNaNs(bool B) {
assert(isa<FPMathOperator>(this) && "setting fast-math flag on invalid op");
cast<FPMathOperator>(this)->setHasNoNaNs(B);
}
void Instruction::setHasNoInfs(bool B) {
assert(isa<FPMathOperator>(this) && "setting fast-math flag on invalid op");
cast<FPMathOperator>(this)->setHasNoInfs(B);
}
void Instruction::setHasNoSignedZeros(bool B) {
assert(isa<FPMathOperator>(this) && "setting fast-math flag on invalid op");
cast<FPMathOperator>(this)->setHasNoSignedZeros(B);
}
void Instruction::setHasAllowReciprocal(bool B) {
assert(isa<FPMathOperator>(this) && "setting fast-math flag on invalid op");
cast<FPMathOperator>(this)->setHasAllowReciprocal(B);
}
[IR] add set function for FMF 'contract' This was missed when the flag was added with D31164.
2020-05-27 20:29:09 +08:00
void Instruction::setHasAllowContract(bool B) {
assert(isa<FPMathOperator>(this) && "setting fast-math flag on invalid op");
cast<FPMathOperator>(this)->setHasAllowContract(B);
}
[IR] redefine 'UnsafeAlgebra' / 'reassoc' fast-math-flags and add 'trans' fast-math-flag As discussed on llvm-dev: http://lists.llvm.org/pipermail/llvm-dev/2016-November/107104.html and again more recently: http://lists.llvm.org/pipermail/llvm-dev/2017-October/118118.html ...this is a step in cleaning up our fast-math-flags implementation in IR to better match the capabilities of both clang's user-visible flags and the backend's flags for SDNode. As proposed in the above threads, we're replacing the 'UnsafeAlgebra' bit (which had the 'umbrella' meaning that all flags are set) with a new bit that only applies to algebraic reassociation - 'AllowReassoc'. We're also adding a bit to allow approximations for library functions called 'ApproxFunc' (this was initially proposed as 'libm' or similar). ...and we're out of bits. 7 bits ought to be enough for anyone, right? :) FWIW, I did look at getting this out of SubclassOptionalData via SubclassData (spacious 16-bits), but that's apparently already used for other purposes. Also, I don't think we can just add a field to FPMathOperator because Operator is not intended to be instantiated. We'll defer movement of FMF to another day. We keep the 'fast' keyword. I thought about removing that, but seeing IR like this: %f.fast = fadd reassoc nnan ninf nsz arcp contract afn float %op1, %op2 ...made me think we want to keep the shortcut synonym. Finally, this change is binary incompatible with existing IR as seen in the compatibility tests. This statement: "Newer releases can ignore features from older releases, but they cannot miscompile them. For example, if nsw is ever replaced with something else, dropping it would be a valid way to upgrade the IR." ( http://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility ) ...provides the flexibility we want to make this change without requiring a new IR version. Ie, we're not loosening the FP strictness of existing IR. At worst, we will fail to optimize some previously 'fast' code because it's no longer recognized as 'fast'. This should get fixed as we audit/squash all of the uses of 'isFast()'. Note: an inter-dependent clang commit to use the new API name should closely follow commit. Differential Revision: https://reviews.llvm.org/D39304 llvm-svn: 317488
2017-11-07 00:27:15 +08:00
void Instruction::setHasApproxFunc(bool B) {
assert(isa<FPMathOperator>(this) && "setting fast-math flag on invalid op");
cast<FPMathOperator>(this)->setHasApproxFunc(B);
}
Fast-math interfaces for Instructions Add in getter/setter methods for Instructions, allowing them to be the interface to FPMathOperator similarly to now NUS/NSW is handled. llvm-svn: 168642
2012-11-27 08:41:22 +08:00
void Instruction::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);
}
[IR] redefine 'UnsafeAlgebra' / 'reassoc' fast-math-flags and add 'trans' fast-math-flag As discussed on llvm-dev: http://lists.llvm.org/pipermail/llvm-dev/2016-November/107104.html and again more recently: http://lists.llvm.org/pipermail/llvm-dev/2017-October/118118.html ...this is a step in cleaning up our fast-math-flags implementation in IR to better match the capabilities of both clang's user-visible flags and the backend's flags for SDNode. As proposed in the above threads, we're replacing the 'UnsafeAlgebra' bit (which had the 'umbrella' meaning that all flags are set) with a new bit that only applies to algebraic reassociation - 'AllowReassoc'. We're also adding a bit to allow approximations for library functions called 'ApproxFunc' (this was initially proposed as 'libm' or similar). ...and we're out of bits. 7 bits ought to be enough for anyone, right? :) FWIW, I did look at getting this out of SubclassOptionalData via SubclassData (spacious 16-bits), but that's apparently already used for other purposes. Also, I don't think we can just add a field to FPMathOperator because Operator is not intended to be instantiated. We'll defer movement of FMF to another day. We keep the 'fast' keyword. I thought about removing that, but seeing IR like this: %f.fast = fadd reassoc nnan ninf nsz arcp contract afn float %op1, %op2 ...made me think we want to keep the shortcut synonym. Finally, this change is binary incompatible with existing IR as seen in the compatibility tests. This statement: "Newer releases can ignore features from older releases, but they cannot miscompile them. For example, if nsw is ever replaced with something else, dropping it would be a valid way to upgrade the IR." ( http://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility ) ...provides the flexibility we want to make this change without requiring a new IR version. Ie, we're not loosening the FP strictness of existing IR. At worst, we will fail to optimize some previously 'fast' code because it's no longer recognized as 'fast'. This should get fixed as we audit/squash all of the uses of 'isFast()'. Note: an inter-dependent clang commit to use the new API name should closely follow commit. Differential Revision: https://reviews.llvm.org/D39304 llvm-svn: 317488
2017-11-07 00:27:15 +08:00
bool Instruction::isFast() 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");
[IR] redefine 'UnsafeAlgebra' / 'reassoc' fast-math-flags and add 'trans' fast-math-flag As discussed on llvm-dev: http://lists.llvm.org/pipermail/llvm-dev/2016-November/107104.html and again more recently: http://lists.llvm.org/pipermail/llvm-dev/2017-October/118118.html ...this is a step in cleaning up our fast-math-flags implementation in IR to better match the capabilities of both clang's user-visible flags and the backend's flags for SDNode. As proposed in the above threads, we're replacing the 'UnsafeAlgebra' bit (which had the 'umbrella' meaning that all flags are set) with a new bit that only applies to algebraic reassociation - 'AllowReassoc'. We're also adding a bit to allow approximations for library functions called 'ApproxFunc' (this was initially proposed as 'libm' or similar). ...and we're out of bits. 7 bits ought to be enough for anyone, right? :) FWIW, I did look at getting this out of SubclassOptionalData via SubclassData (spacious 16-bits), but that's apparently already used for other purposes. Also, I don't think we can just add a field to FPMathOperator because Operator is not intended to be instantiated. We'll defer movement of FMF to another day. We keep the 'fast' keyword. I thought about removing that, but seeing IR like this: %f.fast = fadd reassoc nnan ninf nsz arcp contract afn float %op1, %op2 ...made me think we want to keep the shortcut synonym. Finally, this change is binary incompatible with existing IR as seen in the compatibility tests. This statement: "Newer releases can ignore features from older releases, but they cannot miscompile them. For example, if nsw is ever replaced with something else, dropping it would be a valid way to upgrade the IR." ( http://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility ) ...provides the flexibility we want to make this change without requiring a new IR version. Ie, we're not loosening the FP strictness of existing IR. At worst, we will fail to optimize some previously 'fast' code because it's no longer recognized as 'fast'. This should get fixed as we audit/squash all of the uses of 'isFast()'. Note: an inter-dependent clang commit to use the new API name should closely follow commit. Differential Revision: https://reviews.llvm.org/D39304 llvm-svn: 317488
2017-11-07 00:27:15 +08:00
return cast<FPMathOperator>(this)->isFast();
}
bool Instruction::hasAllowReassoc() const {
assert(isa<FPMathOperator>(this) && "getting fast-math flag on invalid op");
return cast<FPMathOperator>(this)->hasAllowReassoc();
Fast-math interfaces for Instructions Add in getter/setter methods for Instructions, allowing them to be the interface to FPMathOperator similarly to now NUS/NSW is handled. llvm-svn: 168642
2012-11-27 08:41:22 +08:00
}
bool Instruction::hasNoNaNs() const {
Fix assert comments in Instruction.cpp. llvm-svn: 210684
2014-06-12 02:26:29 +08:00
assert(isa<FPMathOperator>(this) && "getting fast-math flag on invalid op");
Fast-math interfaces for Instructions Add in getter/setter methods for Instructions, allowing them to be the interface to FPMathOperator similarly to now NUS/NSW is handled. llvm-svn: 168642
2012-11-27 08:41:22 +08:00
return cast<FPMathOperator>(this)->hasNoNaNs();
}
bool Instruction::hasNoInfs() const {
Fix assert comments in Instruction.cpp. llvm-svn: 210684
2014-06-12 02:26:29 +08:00
assert(isa<FPMathOperator>(this) && "getting fast-math flag on invalid op");
Fast-math interfaces for Instructions Add in getter/setter methods for Instructions, allowing them to be the interface to FPMathOperator similarly to now NUS/NSW is handled. llvm-svn: 168642
2012-11-27 08:41:22 +08:00
return cast<FPMathOperator>(this)->hasNoInfs();
}
bool Instruction::hasNoSignedZeros() const {
Fix assert comments in Instruction.cpp. llvm-svn: 210684
2014-06-12 02:26:29 +08:00
assert(isa<FPMathOperator>(this) && "getting fast-math flag on invalid op");
Fast-math interfaces for Instructions Add in getter/setter methods for Instructions, allowing them to be the interface to FPMathOperator similarly to now NUS/NSW is handled. llvm-svn: 168642
2012-11-27 08:41:22 +08:00
return cast<FPMathOperator>(this)->hasNoSignedZeros();
}
bool Instruction::hasAllowReciprocal() const {
Fix assert comments in Instruction.cpp. llvm-svn: 210684
2014-06-12 02:26:29 +08:00
assert(isa<FPMathOperator>(this) && "getting fast-math flag on invalid op");
Fast-math interfaces for Instructions Add in getter/setter methods for Instructions, allowing them to be the interface to FPMathOperator similarly to now NUS/NSW is handled. llvm-svn: 168642
2012-11-27 08:41:22 +08:00
return cast<FPMathOperator>(this)->hasAllowReciprocal();
}
[IR] Add AllowContract to FastMathFlags -ffp-contract=fast does not currently work with LTO because it's passed as a TargetOption to the backend rather than in the IR. This adds it to FastMathFlags. This is toward fixing PR25721 Differential Revision: https://reviews.llvm.org/D31164 llvm-svn: 298939
2017-03-29 04:11:52 +08:00
bool Instruction::hasAllowContract() const {
assert(isa<FPMathOperator>(this) && "getting fast-math flag on invalid op");
return cast<FPMathOperator>(this)->hasAllowContract();
}
[IR] redefine 'UnsafeAlgebra' / 'reassoc' fast-math-flags and add 'trans' fast-math-flag As discussed on llvm-dev: http://lists.llvm.org/pipermail/llvm-dev/2016-November/107104.html and again more recently: http://lists.llvm.org/pipermail/llvm-dev/2017-October/118118.html ...this is a step in cleaning up our fast-math-flags implementation in IR to better match the capabilities of both clang's user-visible flags and the backend's flags for SDNode. As proposed in the above threads, we're replacing the 'UnsafeAlgebra' bit (which had the 'umbrella' meaning that all flags are set) with a new bit that only applies to algebraic reassociation - 'AllowReassoc'. We're also adding a bit to allow approximations for library functions called 'ApproxFunc' (this was initially proposed as 'libm' or similar). ...and we're out of bits. 7 bits ought to be enough for anyone, right? :) FWIW, I did look at getting this out of SubclassOptionalData via SubclassData (spacious 16-bits), but that's apparently already used for other purposes. Also, I don't think we can just add a field to FPMathOperator because Operator is not intended to be instantiated. We'll defer movement of FMF to another day. We keep the 'fast' keyword. I thought about removing that, but seeing IR like this: %f.fast = fadd reassoc nnan ninf nsz arcp contract afn float %op1, %op2 ...made me think we want to keep the shortcut synonym. Finally, this change is binary incompatible with existing IR as seen in the compatibility tests. This statement: "Newer releases can ignore features from older releases, but they cannot miscompile them. For example, if nsw is ever replaced with something else, dropping it would be a valid way to upgrade the IR." ( http://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility ) ...provides the flexibility we want to make this change without requiring a new IR version. Ie, we're not loosening the FP strictness of existing IR. At worst, we will fail to optimize some previously 'fast' code because it's no longer recognized as 'fast'. This should get fixed as we audit/squash all of the uses of 'isFast()'. Note: an inter-dependent clang commit to use the new API name should closely follow commit. Differential Revision: https://reviews.llvm.org/D39304 llvm-svn: 317488
2017-11-07 00:27:15 +08:00
bool Instruction::hasApproxFunc() const {
assert(isa<FPMathOperator>(this) && "getting fast-math flag on invalid op");
return cast<FPMathOperator>(this)->hasApproxFunc();
}
Fast-math interfaces for Instructions Add in getter/setter methods for Instructions, allowing them to be the interface to FPMathOperator similarly to now NUS/NSW is handled. llvm-svn: 168642
2012-11-27 08:41:22 +08:00
FastMathFlags Instruction::getFastMathFlags() const {
Fix assert comments in Instruction.cpp. llvm-svn: 210684
2014-06-12 02:26:29 +08:00
assert(isa<FPMathOperator>(this) && "getting fast-math flag on invalid op");
Fast-math interfaces for Instructions Add in getter/setter methods for Instructions, allowing them to be the interface to FPMathOperator similarly to now NUS/NSW is handled. llvm-svn: 168642
2012-11-27 08:41:22 +08:00
return cast<FPMathOperator>(this)->getFastMathFlags();
}
add new helper function llvm-svn: 22698
2005-08-08 13:21:50 +08:00
copyFastMathFlags utility and test case llvm-svn: 168943
2012-11-30 05:25:12 +08:00
void Instruction::copyFastMathFlags(const Instruction *I) {
Fix a logic bug when copying fast-math flags. "Setting" does not equal "copying". This bug has sat dormant for 2 reasons: 1. The unit test was not adequate. 2. Every current user of the "copyFastMathFlags" API is operating on a new instruction. (ie, all existing fast-math flags are off). If you copy flags to an existing instruction that has some flags on already, you will not necessarily turn them off as expected. I uncovered this bug while trying to implement a fix for PR20802. llvm-svn: 216939
2014-09-03 04:03:00 +08:00
copyFastMathFlags(I->getFastMathFlags());
copyFastMathFlags utility and test case llvm-svn: 168943
2012-11-30 05:25:12 +08:00
}
[LoopVectorize] Don't preserve nsw/nuw flags on shrunken ops. If we're shrinking a binary operation, it may be the case that the new operations wraps where the old didn't. If this happens, the behavior should be well-defined. So, we can't always carry wrapping flags with us when we shrink operations. If we do, we get incorrect optimizations in cases like: void foo(const unsigned char *from, unsigned char *to, int n) { for (int i = 0; i < n; i++) to[i] = from[i] - 128; } which gets optimized to: void foo(const unsigned char *from, unsigned char *to, int n) { for (int i = 0; i < n; i++) to[i] = from[i] | 128; } Because: - InstCombine turned `sub i32 %from.i, 128` into `add nuw nsw i32 %from.i, 128`. - LoopVectorize vectorized the add to be `add nuw nsw <16 x i8>` with a vector full of `i8 128`s - InstCombine took advantage of the fact that the newly-shrunken add "couldn't wrap", and changed the `add` to an `or`. InstCombine seems happy to figure out whether we can add nuw/nsw on its own, so I just decided to drop the flags. There are already a number of places in LoopVectorize where we rely on InstCombine to clean up. llvm-svn: 305053
2017-06-09 11:56:15 +08:00
void Instruction::copyIRFlags(const Value *V, bool IncludeWrapFlags) {
[EarlyCSE] Take the intersection of flags on instructions EarlyCSE had inconsistent behavior with regards to flag'd instructions: - In some cases, it would pessimize if the available instruction had different flags by not performing CSE. - In other cases, it would miscompile if it replaced an instruction which had no flags with an instruction which has flags. Fix this by being more consistent with our flag handling by utilizing andIRFlags. llvm-svn: 267111
2016-04-22 14:37:45 +08:00
// Copy the wrapping flags.
[LoopVectorize] Don't preserve nsw/nuw flags on shrunken ops. If we're shrinking a binary operation, it may be the case that the new operations wraps where the old didn't. If this happens, the behavior should be well-defined. So, we can't always carry wrapping flags with us when we shrink operations. If we do, we get incorrect optimizations in cases like: void foo(const unsigned char *from, unsigned char *to, int n) { for (int i = 0; i < n; i++) to[i] = from[i] - 128; } which gets optimized to: void foo(const unsigned char *from, unsigned char *to, int n) { for (int i = 0; i < n; i++) to[i] = from[i] | 128; } Because: - InstCombine turned `sub i32 %from.i, 128` into `add nuw nsw i32 %from.i, 128`. - LoopVectorize vectorized the add to be `add nuw nsw <16 x i8>` with a vector full of `i8 128`s - InstCombine took advantage of the fact that the newly-shrunken add "couldn't wrap", and changed the `add` to an `or`. InstCombine seems happy to figure out whether we can add nuw/nsw on its own, so I just decided to drop the flags. There are already a number of places in LoopVectorize where we rely on InstCombine to clean up. llvm-svn: 305053
2017-06-09 11:56:15 +08:00
if (IncludeWrapFlags && isa<OverflowingBinaryOperator>(this)) {
if (auto *OB = dyn_cast<OverflowingBinaryOperator>(V)) {
[GVN] Respect fast-math-flags on fcmps We assumed that flags were only present on binary operators. This is not true, they may also be present on calls and fcmps. llvm-svn: 267113
2016-04-22 14:37:51 +08:00
setHasNoSignedWrap(OB->hasNoSignedWrap());
setHasNoUnsignedWrap(OB->hasNoUnsignedWrap());
}
[EarlyCSE] Take the intersection of flags on instructions EarlyCSE had inconsistent behavior with regards to flag'd instructions: - In some cases, it would pessimize if the available instruction had different flags by not performing CSE. - In other cases, it would miscompile if it replaced an instruction which had no flags with an instruction which has flags. Fix this by being more consistent with our flag handling by utilizing andIRFlags. llvm-svn: 267111
2016-04-22 14:37:45 +08:00
}
// Copy the exact flag.
if (auto *PE = dyn_cast<PossiblyExactOperator>(V))
[GVN] Respect fast-math-flags on fcmps We assumed that flags were only present on binary operators. This is not true, they may also be present on calls and fcmps. llvm-svn: 267113
2016-04-22 14:37:51 +08:00
if (isa<PossiblyExactOperator>(this))
setIsExact(PE->isExact());
[EarlyCSE] Take the intersection of flags on instructions EarlyCSE had inconsistent behavior with regards to flag'd instructions: - In some cases, it would pessimize if the available instruction had different flags by not performing CSE. - In other cases, it would miscompile if it replaced an instruction which had no flags with an instruction which has flags. Fix this by being more consistent with our flag handling by utilizing andIRFlags. llvm-svn: 267111
2016-04-22 14:37:45 +08:00
// Copy the fast-math flags.
if (auto *FP = dyn_cast<FPMathOperator>(V))
[GVN] Respect fast-math-flags on fcmps We assumed that flags were only present on binary operators. This is not true, they may also be present on calls and fcmps. llvm-svn: 267113
2016-04-22 14:37:51 +08:00
if (isa<FPMathOperator>(this))
copyFastMathFlags(FP->getFastMathFlags());
[IR] andIRFlags and copyIRFlags needs to handle GEP We didn't consider the inbounds flag on GEPs leading to downstream users introducing UB. This fixes PR28562. llvm-svn: 275532
2016-07-15 13:02:31 +08:00
if (auto *SrcGEP = dyn_cast<GetElementPtrInst>(V))
if (auto *DestGEP = dyn_cast<GetElementPtrInst>(this))
DestGEP->setIsInBounds(SrcGEP->isInBounds() | DestGEP->isInBounds());
[EarlyCSE] Take the intersection of flags on instructions EarlyCSE had inconsistent behavior with regards to flag'd instructions: - In some cases, it would pessimize if the available instruction had different flags by not performing CSE. - In other cases, it would miscompile if it replaced an instruction which had no flags with an instruction which has flags. Fix this by being more consistent with our flag handling by utilizing andIRFlags. llvm-svn: 267111
2016-04-22 14:37:45 +08:00
}
void Instruction::andIRFlags(const Value *V) {
if (auto *OB = dyn_cast<OverflowingBinaryOperator>(V)) {
[GVN] Respect fast-math-flags on fcmps We assumed that flags were only present on binary operators. This is not true, they may also be present on calls and fcmps. llvm-svn: 267113
2016-04-22 14:37:51 +08:00
if (isa<OverflowingBinaryOperator>(this)) {
setHasNoSignedWrap(hasNoSignedWrap() & OB->hasNoSignedWrap());
setHasNoUnsignedWrap(hasNoUnsignedWrap() & OB->hasNoUnsignedWrap());
}
[EarlyCSE] Take the intersection of flags on instructions EarlyCSE had inconsistent behavior with regards to flag'd instructions: - In some cases, it would pessimize if the available instruction had different flags by not performing CSE. - In other cases, it would miscompile if it replaced an instruction which had no flags with an instruction which has flags. Fix this by being more consistent with our flag handling by utilizing andIRFlags. llvm-svn: 267111
2016-04-22 14:37:45 +08:00
}
if (auto *PE = dyn_cast<PossiblyExactOperator>(V))
[GVN] Respect fast-math-flags on fcmps We assumed that flags were only present on binary operators. This is not true, they may also be present on calls and fcmps. llvm-svn: 267113
2016-04-22 14:37:51 +08:00
if (isa<PossiblyExactOperator>(this))
setIsExact(isExact() & PE->isExact());
[EarlyCSE] Take the intersection of flags on instructions EarlyCSE had inconsistent behavior with regards to flag'd instructions: - In some cases, it would pessimize if the available instruction had different flags by not performing CSE. - In other cases, it would miscompile if it replaced an instruction which had no flags with an instruction which has flags. Fix this by being more consistent with our flag handling by utilizing andIRFlags. llvm-svn: 267111
2016-04-22 14:37:45 +08:00
if (auto *FP = dyn_cast<FPMathOperator>(V)) {
[GVN] Respect fast-math-flags on fcmps We assumed that flags were only present on binary operators. This is not true, they may also be present on calls and fcmps. llvm-svn: 267113
2016-04-22 14:37:51 +08:00
if (isa<FPMathOperator>(this)) {
FastMathFlags FM = getFastMathFlags();
FM &= FP->getFastMathFlags();
copyFastMathFlags(FM);
}
[EarlyCSE] Take the intersection of flags on instructions EarlyCSE had inconsistent behavior with regards to flag'd instructions: - In some cases, it would pessimize if the available instruction had different flags by not performing CSE. - In other cases, it would miscompile if it replaced an instruction which had no flags with an instruction which has flags. Fix this by being more consistent with our flag handling by utilizing andIRFlags. llvm-svn: 267111
2016-04-22 14:37:45 +08:00
}
[IR] andIRFlags and copyIRFlags needs to handle GEP We didn't consider the inbounds flag on GEPs leading to downstream users introducing UB. This fixes PR28562. llvm-svn: 275532
2016-07-15 13:02:31 +08:00
if (auto *SrcGEP = dyn_cast<GetElementPtrInst>(V))
if (auto *DestGEP = dyn_cast<GetElementPtrInst>(this))
DestGEP->setIsInBounds(SrcGEP->isInBounds() & DestGEP->isInBounds());
[EarlyCSE] Take the intersection of flags on instructions EarlyCSE had inconsistent behavior with regards to flag'd instructions: - In some cases, it would pessimize if the available instruction had different flags by not performing CSE. - In other cases, it would miscompile if it replaced an instruction which had no flags with an instruction which has flags. Fix this by being more consistent with our flag handling by utilizing andIRFlags. llvm-svn: 267111
2016-04-22 14:37:45 +08:00
}
copyFastMathFlags utility and test case llvm-svn: 168943
2012-11-30 05:25:12 +08:00
Create a static version of Instruction::getOpcodeName(opCode) that can be invoked with only an opcode (i.e., without an instruction). Move all opCode->opCodeName translations there. llvm-svn: 2900
2002-07-15 07:09:40 +08:00
const char *Instruction::getOpcodeName(unsigned OpCode) {
switch (OpCode) {
// Terminators
Remove support for NOT instruction llvm-svn: 3323
2002-08-15 02:18:02 +08:00
case Ret: return "ret";
case Br: return "br";
Create a static version of Instruction::getOpcodeName(opCode) that can be invoked with only an opcode (i.e., without an instruction). Move all opCode->opCodeName translations there. llvm-svn: 2900
2002-07-15 07:09:40 +08:00
case Switch: return "switch";
rename indbr -> indirectbr to appease the residents of #llvm. llvm-svn: 85351
2009-10-28 08:19:10 +08:00
case IndirectBr: return "indirectbr";
Create a static version of Instruction::getOpcodeName(opCode) that can be invoked with only an opcode (i.e., without an instruction). Move all opCode->opCodeName translations there. llvm-svn: 2900
2002-07-15 07:09:40 +08:00
case Invoke: return "invoke";
Add the 'resume' instruction for the new EH rewrite. This adds the 'resume' instruction class, IR parsing, and bitcode reading and writing. The 'resume' instruction resumes propagation of an existing (in-flight) exception whose unwinding was interrupted with a 'landingpad' instruction (to be added later). llvm-svn: 136589
2011-07-31 14:30:59 +08:00
case Resume: return "resume";
Add support for undef and unreachable llvm-svn: 17041
2004-10-17 02:08:06 +08:00
case Unreachable: return "unreachable";
New EH representation for MSVC compatibility This introduces new instructions neccessary to implement MSVC-compatible exception handling support. Most of the middle-end and none of the back-end haven't been audited or updated to take them into account. Differential Revision: http://reviews.llvm.org/D11097 llvm-svn: 243766
2015-08-01 01:58:14 +08:00
case CleanupRet: return "cleanupret";
case CatchRet: return "catchret";
case CatchPad: return "catchpad";
[IR] Reformulate LLVM's EH funclet IR While we have successfully implemented a funclet-oriented EH scheme on top of LLVM IR, our scheme has some notable deficiencies: - catchendpad and cleanupendpad are necessary in the current design but they are difficult to explain to others, even to seasoned LLVM experts. - catchendpad and cleanupendpad are optimization barriers. They cannot be split and force all potentially throwing call-sites to be invokes. This has a noticable effect on the quality of our code generation. - catchpad, while similar in some aspects to invoke, is fairly awkward. It is unsplittable, starts a funclet, and has control flow to other funclets. - The nesting relationship between funclets is currently a property of control flow edges. Because of this, we are forced to carefully analyze the flow graph to see if there might potentially exist illegal nesting among funclets. While we have logic to clone funclets when they are illegally nested, it would be nicer if we had a representation which forbade them upfront. Let's clean this up a bit by doing the following: - Instead, make catchpad more like cleanuppad and landingpad: no control flow, just a bunch of simple operands; catchpad would be splittable. - Introduce catchswitch, a control flow instruction designed to model the constraints of funclet oriented EH. - Make funclet scoping explicit by having funclet instructions consume the token produced by the funclet which contains them. - Remove catchendpad and cleanupendpad. Their presence can be inferred implicitly using coloring information. N.B. The state numbering code for the CLR has been updated but the veracity of it's output cannot be spoken for. An expert should take a look to make sure the results are reasonable. Reviewers: rnk, JosephTremoulet, andrew.w.kaylor Differential Revision: http://reviews.llvm.org/D15139 llvm-svn: 255422
2015-12-12 13:38:55 +08:00
case CatchSwitch: return "catchswitch";
Implementation of asm-goto support in LLVM This patch accompanies the RFC posted here: http://lists.llvm.org/pipermail/llvm-dev/2018-October/127239.html This patch adds a new CallBr IR instruction to support asm-goto inline assembly like gcc as used by the linux kernel. This instruction is both a call instruction and a terminator instruction with multiple successors. Only inline assembly usage is supported today. This also adds a new INLINEASM_BR opcode to SelectionDAG and MachineIR to represent an INLINEASM block that is also considered a terminator instruction. There will likely be more bug fixes and optimizations to follow this, but we felt it had reached a point where we would like to switch to an incremental development model. Patch by Craig Topper, Alexander Ivchenko, Mikhail Dvoretckii Differential Revision: https://reviews.llvm.org/D53765 llvm-svn: 353563
2019-02-09 04:48:56 +08:00
case CallBr: return "callbr";
Remove trailing whitespace llvm-svn: 21427
2005-04-22 07:48:37 +08:00
[IR] Add a dedicated FNeg IR Instruction The IEEE-754 Standard makes it clear that fneg(x) and fsub(-0.0, x) are two different operations. The former is a bitwise operation, while the latter is an arithmetic operation. This patch creates a dedicated FNeg IR Instruction to model that behavior. Differential Revision: https://reviews.llvm.org/D53877 llvm-svn: 346774
2018-11-14 02:15:47 +08:00
// Standard unary operators...
case FNeg: return "fneg";
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";
[IR] Redefine Freeze instruction Summary: This patch redefines freeze instruction from being UnaryOperator to a subclass of UnaryInstruction. ConstantExpr freeze is removed, as discussed in the previous review. FreezeOperator is not added because there's no ConstantExpr freeze. `freeze i8* null` test is added to `test/Bindings/llvm-c/freeze.ll` as well, because the null pointer-related bug in `tools/llvm-c/echo.cpp` is now fixed. InstVisitor has visitFreeze now because freeze is not unaryop anymore. Reviewers: whitequark, deadalnix, craig.topper, jdoerfert, lebedev.ri Reviewed By: craig.topper, lebedev.ri Subscribers: regehr, nlopes, mehdi_amini, hiraditya, steven_wu, dexonsmith, jfb, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69932
2019-11-07 00:17:49 +08:00
case Freeze: return "freeze";
Add support for the new va_arg instruction llvm-svn: 6029
2003-05-08 10:44:12 +08:00
Create a static version of Instruction::getOpcodeName(opCode) that can be invoked with only an opcode (i.e., without an instruction). Move all opCode->opCodeName translations there. llvm-svn: 2900
2002-07-15 07:09:40 +08:00
default: return "<Invalid operator> ";
}
}
New isAssociative/isCommutative inspection methods, graciously contributed by Casey Carter. llvm-svn: 4459
2002-10-31 12:14:01 +08:00
fix documentation comments; NFC llvm-svn: 283361
2016-10-06 02:51:12 +08:00
/// Return true if both instructions have the same special state. This must be
NFC: keep comment up to date MergeFunctions was refactored a while ago, and Instruction.cpp's comments went out of sync. The content did as well, will fix later. llvm-svn: 266007
2016-04-12 06:30:37 +08:00
/// kept in sync with FunctionComparator::cmpOperations in
/// lib/Transforms/IPO/MergeFunctions.cpp.
Factor out comparison of Instruction "special" states. No functional change. llvm-svn: 209688
2014-05-28 05:35:46 +08:00
static bool haveSameSpecialState(const Instruction *I1, const Instruction *I2,
bool IgnoreAlignment = false) {
assert(I1->getOpcode() == I2->getOpcode() &&
"Can not compare special state of different instructions");
Check alloca's special state Following up to a similar fix in MergeFunctions: r266022. This patch keeps both in sync, it would be nice to not have to do this. It doesn't look like there's an easy way to test this code directly at the moment: AFAICT all currect uses of isSameOperationAs are looking at instructions deep inside a function. IndVarSimplify/pr24952.ll and InstMerge/st_sink_* look at alloca inadvertently but are brittle tests. llvm-svn: 266099
2016-04-13 02:06:55 +08:00
if (const AllocaInst *AI = dyn_cast<AllocaInst>(I1))
return AI->getAllocatedType() == cast<AllocaInst>(I2)->getAllocatedType() &&
(AI->getAlignment() == cast<AllocaInst>(I2)->getAlignment() ||
IgnoreAlignment);
Factor out comparison of Instruction "special" states. No functional change. llvm-svn: 209688
2014-05-28 05:35:46 +08:00
if (const LoadInst *LI = dyn_cast<LoadInst>(I1))
return LI->isVolatile() == cast<LoadInst>(I2)->isVolatile() &&
(LI->getAlignment() == cast<LoadInst>(I2)->getAlignment() ||
IgnoreAlignment) &&
LI->getOrdering() == cast<LoadInst>(I2)->getOrdering() &&
Enhance synchscope representation OpenCL 2.0 introduces the notion of memory scopes in atomic operations to global and local memory. These scopes restrict how synchronization is achieved, which can result in improved performance. This change extends existing notion of synchronization scopes in LLVM to support arbitrary scopes expressed as target-specific strings, in addition to the already defined scopes (single thread, system). The LLVM IR and MIR syntax for expressing synchronization scopes has changed to use *syncscope("<scope>")*, where <scope> can be "singlethread" (this replaces *singlethread* keyword), or a target-specific name. As before, if the scope is not specified, it defaults to CrossThread/System scope. Implementation details: - Mapping from synchronization scope name/string to synchronization scope id is stored in LLVM context; - CrossThread/System and SingleThread scopes are pre-defined to efficiently check for known scopes without comparing strings; - Synchronization scope names are stored in SYNC_SCOPE_NAMES_BLOCK in the bitcode. Differential Revision: https://reviews.llvm.org/D21723 llvm-svn: 307722
2017-07-12 06:23:00 +08:00
LI->getSyncScopeID() == cast<LoadInst>(I2)->getSyncScopeID();
Factor out comparison of Instruction "special" states. No functional change. llvm-svn: 209688
2014-05-28 05:35:46 +08:00
if (const StoreInst *SI = dyn_cast<StoreInst>(I1))
return SI->isVolatile() == cast<StoreInst>(I2)->isVolatile() &&
(SI->getAlignment() == cast<StoreInst>(I2)->getAlignment() ||
IgnoreAlignment) &&
SI->getOrdering() == cast<StoreInst>(I2)->getOrdering() &&
Enhance synchscope representation OpenCL 2.0 introduces the notion of memory scopes in atomic operations to global and local memory. These scopes restrict how synchronization is achieved, which can result in improved performance. This change extends existing notion of synchronization scopes in LLVM to support arbitrary scopes expressed as target-specific strings, in addition to the already defined scopes (single thread, system). The LLVM IR and MIR syntax for expressing synchronization scopes has changed to use *syncscope("<scope>")*, where <scope> can be "singlethread" (this replaces *singlethread* keyword), or a target-specific name. As before, if the scope is not specified, it defaults to CrossThread/System scope. Implementation details: - Mapping from synchronization scope name/string to synchronization scope id is stored in LLVM context; - CrossThread/System and SingleThread scopes are pre-defined to efficiently check for known scopes without comparing strings; - Synchronization scope names are stored in SYNC_SCOPE_NAMES_BLOCK in the bitcode. Differential Revision: https://reviews.llvm.org/D21723 llvm-svn: 307722
2017-07-12 06:23:00 +08:00
SI->getSyncScopeID() == cast<StoreInst>(I2)->getSyncScopeID();
Factor out comparison of Instruction "special" states. No functional change. llvm-svn: 209688
2014-05-28 05:35:46 +08:00
if (const CmpInst *CI = dyn_cast<CmpInst>(I1))
return CI->getPredicate() == cast<CmpInst>(I2)->getPredicate();
if (const CallInst *CI = dyn_cast<CallInst>(I1))
return CI->isTailCall() == cast<CallInst>(I2)->isTailCall() &&
CI->getCallingConv() == cast<CallInst>(I2)->getCallingConv() &&
Teach haveSameSpecialState about operand bundles llvm-svn: 255527
2015-12-15 03:11:35 +08:00
CI->getAttributes() == cast<CallInst>(I2)->getAttributes() &&
CI->hasIdenticalOperandBundleSchema(*cast<CallInst>(I2));
Factor out comparison of Instruction "special" states. No functional change. llvm-svn: 209688
2014-05-28 05:35:46 +08:00
if (const InvokeInst *CI = dyn_cast<InvokeInst>(I1))
return CI->getCallingConv() == cast<InvokeInst>(I2)->getCallingConv() &&
Teach haveSameSpecialState about operand bundles llvm-svn: 255527
2015-12-15 03:11:35 +08:00
CI->getAttributes() == cast<InvokeInst>(I2)->getAttributes() &&
CI->hasIdenticalOperandBundleSchema(*cast<InvokeInst>(I2));
Implementation of asm-goto support in LLVM This patch accompanies the RFC posted here: http://lists.llvm.org/pipermail/llvm-dev/2018-October/127239.html This patch adds a new CallBr IR instruction to support asm-goto inline assembly like gcc as used by the linux kernel. This instruction is both a call instruction and a terminator instruction with multiple successors. Only inline assembly usage is supported today. This also adds a new INLINEASM_BR opcode to SelectionDAG and MachineIR to represent an INLINEASM block that is also considered a terminator instruction. There will likely be more bug fixes and optimizations to follow this, but we felt it had reached a point where we would like to switch to an incremental development model. Patch by Craig Topper, Alexander Ivchenko, Mikhail Dvoretckii Differential Revision: https://reviews.llvm.org/D53765 llvm-svn: 353563
2019-02-09 04:48:56 +08:00
if (const CallBrInst *CI = dyn_cast<CallBrInst>(I1))
return CI->getCallingConv() == cast<CallBrInst>(I2)->getCallingConv() &&
CI->getAttributes() == cast<CallBrInst>(I2)->getAttributes() &&
CI->hasIdenticalOperandBundleSchema(*cast<CallBrInst>(I2));
Factor out comparison of Instruction "special" states. No functional change. llvm-svn: 209688
2014-05-28 05:35:46 +08:00
if (const InsertValueInst *IVI = dyn_cast<InsertValueInst>(I1))
return IVI->getIndices() == cast<InsertValueInst>(I2)->getIndices();
if (const ExtractValueInst *EVI = dyn_cast<ExtractValueInst>(I1))
return EVI->getIndices() == cast<ExtractValueInst>(I2)->getIndices();
if (const FenceInst *FI = dyn_cast<FenceInst>(I1))
return FI->getOrdering() == cast<FenceInst>(I2)->getOrdering() &&
Enhance synchscope representation OpenCL 2.0 introduces the notion of memory scopes in atomic operations to global and local memory. These scopes restrict how synchronization is achieved, which can result in improved performance. This change extends existing notion of synchronization scopes in LLVM to support arbitrary scopes expressed as target-specific strings, in addition to the already defined scopes (single thread, system). The LLVM IR and MIR syntax for expressing synchronization scopes has changed to use *syncscope("<scope>")*, where <scope> can be "singlethread" (this replaces *singlethread* keyword), or a target-specific name. As before, if the scope is not specified, it defaults to CrossThread/System scope. Implementation details: - Mapping from synchronization scope name/string to synchronization scope id is stored in LLVM context; - CrossThread/System and SingleThread scopes are pre-defined to efficiently check for known scopes without comparing strings; - Synchronization scope names are stored in SYNC_SCOPE_NAMES_BLOCK in the bitcode. Differential Revision: https://reviews.llvm.org/D21723 llvm-svn: 307722
2017-07-12 06:23:00 +08:00
FI->getSyncScopeID() == cast<FenceInst>(I2)->getSyncScopeID();
Factor out comparison of Instruction "special" states. No functional change. llvm-svn: 209688
2014-05-28 05:35:46 +08:00
if (const AtomicCmpXchgInst *CXI = dyn_cast<AtomicCmpXchgInst>(I1))
return CXI->isVolatile() == cast<AtomicCmpXchgInst>(I2)->isVolatile() &&
IR: add "cmpxchg weak" variant to support permitted failure. This commit adds a weak variant of the cmpxchg operation, as described in C++11. A cmpxchg instruction with this modifier is permitted to fail to store, even if the comparison indicated it should. As a result, cmpxchg instructions must return a flag indicating success in addition to their original iN value loaded. Thus, for uniformity *all* cmpxchg instructions now return "{ iN, i1 }". The second flag is 1 when the store succeeded. At the DAG level, a new ATOMIC_CMP_SWAP_WITH_SUCCESS node has been added as the natural representation for the new cmpxchg instructions. It is a strong cmpxchg. By default this gets Expanded to the existing ATOMIC_CMP_SWAP during Legalization, so existing backends should see no change in behaviour. If they wish to deal with the enhanced node instead, they can call setOperationAction on it. Beware: as a node with 2 results, it cannot be selected from TableGen. Currently, no use is made of the extra information provided in this patch. Test updates are almost entirely adapting the input IR to the new scheme. Summary for out of tree users: ------------------------------ + Legacy Bitcode files are upgraded during read. + Legacy assembly IR files will be invalid. + Front-ends must adapt to different type for "cmpxchg". + Backends should be unaffected by default. llvm-svn: 210903
2014-06-13 22:24:07 +08:00
CXI->isWeak() == cast<AtomicCmpXchgInst>(I2)->isWeak() &&
Factor out comparison of Instruction "special" states. No functional change. llvm-svn: 209688
2014-05-28 05:35:46 +08:00
CXI->getSuccessOrdering() ==
cast<AtomicCmpXchgInst>(I2)->getSuccessOrdering() &&
CXI->getFailureOrdering() ==
cast<AtomicCmpXchgInst>(I2)->getFailureOrdering() &&
Enhance synchscope representation OpenCL 2.0 introduces the notion of memory scopes in atomic operations to global and local memory. These scopes restrict how synchronization is achieved, which can result in improved performance. This change extends existing notion of synchronization scopes in LLVM to support arbitrary scopes expressed as target-specific strings, in addition to the already defined scopes (single thread, system). The LLVM IR and MIR syntax for expressing synchronization scopes has changed to use *syncscope("<scope>")*, where <scope> can be "singlethread" (this replaces *singlethread* keyword), or a target-specific name. As before, if the scope is not specified, it defaults to CrossThread/System scope. Implementation details: - Mapping from synchronization scope name/string to synchronization scope id is stored in LLVM context; - CrossThread/System and SingleThread scopes are pre-defined to efficiently check for known scopes without comparing strings; - Synchronization scope names are stored in SYNC_SCOPE_NAMES_BLOCK in the bitcode. Differential Revision: https://reviews.llvm.org/D21723 llvm-svn: 307722
2017-07-12 06:23:00 +08:00
CXI->getSyncScopeID() ==
cast<AtomicCmpXchgInst>(I2)->getSyncScopeID();
Factor out comparison of Instruction "special" states. No functional change. llvm-svn: 209688
2014-05-28 05:35:46 +08:00
if (const AtomicRMWInst *RMWI = dyn_cast<AtomicRMWInst>(I1))
return RMWI->getOperation() == cast<AtomicRMWInst>(I2)->getOperation() &&
RMWI->isVolatile() == cast<AtomicRMWInst>(I2)->isVolatile() &&
RMWI->getOrdering() == cast<AtomicRMWInst>(I2)->getOrdering() &&
Enhance synchscope representation OpenCL 2.0 introduces the notion of memory scopes in atomic operations to global and local memory. These scopes restrict how synchronization is achieved, which can result in improved performance. This change extends existing notion of synchronization scopes in LLVM to support arbitrary scopes expressed as target-specific strings, in addition to the already defined scopes (single thread, system). The LLVM IR and MIR syntax for expressing synchronization scopes has changed to use *syncscope("<scope>")*, where <scope> can be "singlethread" (this replaces *singlethread* keyword), or a target-specific name. As before, if the scope is not specified, it defaults to CrossThread/System scope. Implementation details: - Mapping from synchronization scope name/string to synchronization scope id is stored in LLVM context; - CrossThread/System and SingleThread scopes are pre-defined to efficiently check for known scopes without comparing strings; - Synchronization scope names are stored in SYNC_SCOPE_NAMES_BLOCK in the bitcode. Differential Revision: https://reviews.llvm.org/D21723 llvm-svn: 307722
2017-07-12 06:23:00 +08:00
RMWI->getSyncScopeID() == cast<AtomicRMWInst>(I2)->getSyncScopeID();
Remove "mask" operand from shufflevector. Instead, represent the mask as out-of-line data in the instruction. This should be more efficient in the places that currently use getShuffleVector(), and paves the way for further changes to add new shuffles for scalable vectors. This doesn't change the syntax in textual IR. And I don't currently plan to change the bitcode encoding in this patch, although we'll probably need to do something once we extend shufflevector for scalable types. I expect that once this is finished, we can then replace the raw "mask" with something more appropriate for scalable vectors. Not sure exactly what this looks like at the moment, but there are a few different ways we could handle it. Maybe we could try to describe specific shuffles. Or maybe we could define it in terms of a function to convert a fixed-length array into an appropriate scalable vector, using a "step", or something like that. Differential Revision: https://reviews.llvm.org/D72467
2020-04-01 04:08:59 +08:00
if (const ShuffleVectorInst *SVI = dyn_cast<ShuffleVectorInst>(I1))
return SVI->getShuffleMask() ==
cast<ShuffleVectorInst>(I2)->getShuffleMask();
Factor out comparison of Instruction "special" states. No functional change. llvm-svn: 209688
2014-05-28 05:35:46 +08:00
return true;
}
improve const correctness. llvm-svn: 60168
2008-11-27 16:39:18 +08:00
bool Instruction::isIdenticalTo(const Instruction *I) const {
This should use isIndenticalToWhenDefined. llvm-svn: 80039
2009-08-26 06:24:20 +08:00
return isIdenticalToWhenDefined(I) &&
Rename Instruction::isIdenticalTo to Instruction::isIdenticalToWhenDefined, and introduce a new Instruction::isIdenticalTo which tests for full identity, including the SubclassOptionalData flags. Also, fix the Instruction::clone implementations to preserve the SubclassOptionalData flags. Finally, teach several optimizations how to handle SubclassOptionalData correctly, given these changes. This fixes the counterintuitive behavior of isIdenticalTo not comparing the full value, and clone not returning an identical clone, as well as some subtle bugs that could be caused by these. Thanks to Nick Lewycky for reporting this, and for an initial patch! llvm-svn: 80038
2009-08-26 06:11:20 +08:00
SubclassOptionalData == I->SubclassOptionalData;
}
bool Instruction::isIdenticalToWhenDefined(const Instruction *I) const {
Add method llvm-svn: 18368
2004-11-30 10:51:53 +08:00
if (getOpcode() != I->getOpcode() ||
getNumOperands() != I->getNumOperands() ||
getType() != I->getType())
return false;
Instruction::isIdenticalToWhenDefined(): Check getNumOperands() in advance of std::equal(op) to appease MSVC Debug build. MSVC Debug build is confused with (possibly invalid) op_begin(), if op_begin() == op_end(). llvm-svn: 210000
2014-06-02 09:35:34 +08:00
// If both instructions have no operands, they are identical.
if (getNumOperands() == 0 && I->getNumOperands() == 0)
return haveSameSpecialState(this, I);
[InstCombine] Take 2: Perform trivial PHI CSE The original take was 6102310d814ad73eab60a88b21dd70874f7a056f, which taught InstSimplify to do that, which seemed better at time, since we got EarlyCSE support for free. However, it was proven that we can not do that there, the simplified-to PHI would not be reachable from the original PHI, and that is not something InstSimplify is allowed to do, as noted in the commit ed90f15efb40d26b5d3ead3bb8e9e284218e0186 that reverted it : > It appears to cause compilation non-determinism and caused stage3 mismatches. However InstCombine already does many different optimizations, so it should be a safe place to do it here. Note that we still can't just compare incoming values ranges, because there is no guarantee that these PHI's we'd simplify to were already re-visited and sorted. However coming up with a test is problematic. Effects on vanilla llvm test-suite + RawSpeed: ``` | statistic name | baseline | proposed | Δ | % | |%| | |----------------------------------------------------|-----------|-----------|-------:|---------:|---------:| | instcombine.NumPHICSEs | 0 | 22228 | 22228 | 0.00% | 0.00% | | asm-printer.EmittedInsts | 7942329 | 7942456 | 127 | 0.00% | 0.00% | | assembler.ObjectBytes | 254295632 | 254313792 | 18160 | 0.01% | 0.01% | | early-cse.NumCSE | 2183283 | 2183272 | -11 | 0.00% | 0.00% | | early-cse.NumSimplify | 550105 | 541842 | -8263 | -1.50% | 1.50% | | instcombine.NumAggregateReconstructionsSimplified | 73 | 4506 | 4433 | 6072.60% | 6072.60% | | instcombine.NumCombined | 3640311 | 3666911 | 26600 | 0.73% | 0.73% | | instcombine.NumDeadInst | 1778204 | 1783318 | 5114 | 0.29% | 0.29% | | instcount.NumCallInst | 1758395 | 1758804 | 409 | 0.02% | 0.02% | | instcount.NumInvokeInst | 59478 | 59502 | 24 | 0.04% | 0.04% | | instcount.NumPHIInst | 330557 | 330549 | -8 | 0.00% | 0.00% | | instcount.TotalBlocks | 1077138 | 1077221 | 83 | 0.01% | 0.01% | | instcount.TotalFuncs | 101442 | 101441 | -1 | 0.00% | 0.00% | | instcount.TotalInsts | 8831946 | 8832611 | 665 | 0.01% | 0.01% | | simplifycfg.NumInvokes | 4300 | 4410 | 110 | 2.56% | 2.56% | | simplifycfg.NumSimpl | 1019813 | 999740 | -20073 | -1.97% | 1.97% | ``` So it fires ~22k times, which is less than ~24k the take 1 did. It allows foldAggregateConstructionIntoAggregateReuse() to actually work after PHI-of-extractvalue folds did their thing. Previously SimplifyCFG would have done this PHI CSE, of all places. Additionally, allows some more `invoke`->`call` folds to happen (+110, +2.56%). All in all, expectedly, this catches less things overall, but all the motivational cases are still caught, so all good.
2020-08-29 15:42:38 +08:00
// PHI nodes are special.
Revert "[InstSimplify][EarlyCSE] Try to CSE PHI nodes in the same basic block" This reverts commit 6102310d814ad73eab60a88b21dd70874f7a056f. It appears to cause compilation non-determinism and caused stage3 mismatches.
2020-08-29 07:32:25 +08:00
if (const PHINode *thisPHI = dyn_cast<PHINode>(this)) {
const PHINode *otherPHI = cast<PHINode>(I);
[NFC] Instruction::isIdenticalToWhenDefined(): s/nessesairly/necessarily/
2020-08-29 19:53:15 +08:00
// PHI nodes don't necessarily have their operands in the same order,
[InstCombine] Take 2: Perform trivial PHI CSE The original take was 6102310d814ad73eab60a88b21dd70874f7a056f, which taught InstSimplify to do that, which seemed better at time, since we got EarlyCSE support for free. However, it was proven that we can not do that there, the simplified-to PHI would not be reachable from the original PHI, and that is not something InstSimplify is allowed to do, as noted in the commit ed90f15efb40d26b5d3ead3bb8e9e284218e0186 that reverted it : > It appears to cause compilation non-determinism and caused stage3 mismatches. However InstCombine already does many different optimizations, so it should be a safe place to do it here. Note that we still can't just compare incoming values ranges, because there is no guarantee that these PHI's we'd simplify to were already re-visited and sorted. However coming up with a test is problematic. Effects on vanilla llvm test-suite + RawSpeed: ``` | statistic name | baseline | proposed | Δ | % | |%| | |----------------------------------------------------|-----------|-----------|-------:|---------:|---------:| | instcombine.NumPHICSEs | 0 | 22228 | 22228 | 0.00% | 0.00% | | asm-printer.EmittedInsts | 7942329 | 7942456 | 127 | 0.00% | 0.00% | | assembler.ObjectBytes | 254295632 | 254313792 | 18160 | 0.01% | 0.01% | | early-cse.NumCSE | 2183283 | 2183272 | -11 | 0.00% | 0.00% | | early-cse.NumSimplify | 550105 | 541842 | -8263 | -1.50% | 1.50% | | instcombine.NumAggregateReconstructionsSimplified | 73 | 4506 | 4433 | 6072.60% | 6072.60% | | instcombine.NumCombined | 3640311 | 3666911 | 26600 | 0.73% | 0.73% | | instcombine.NumDeadInst | 1778204 | 1783318 | 5114 | 0.29% | 0.29% | | instcount.NumCallInst | 1758395 | 1758804 | 409 | 0.02% | 0.02% | | instcount.NumInvokeInst | 59478 | 59502 | 24 | 0.04% | 0.04% | | instcount.NumPHIInst | 330557 | 330549 | -8 | 0.00% | 0.00% | | instcount.TotalBlocks | 1077138 | 1077221 | 83 | 0.01% | 0.01% | | instcount.TotalFuncs | 101442 | 101441 | -1 | 0.00% | 0.00% | | instcount.TotalInsts | 8831946 | 8832611 | 665 | 0.01% | 0.01% | | simplifycfg.NumInvokes | 4300 | 4410 | 110 | 2.56% | 2.56% | | simplifycfg.NumSimpl | 1019813 | 999740 | -20073 | -1.97% | 1.97% | ``` So it fires ~22k times, which is less than ~24k the take 1 did. It allows foldAggregateConstructionIntoAggregateReuse() to actually work after PHI-of-extractvalue folds did their thing. Previously SimplifyCFG would have done this PHI CSE, of all places. Additionally, allows some more `invoke`->`call` folds to happen (+110, +2.56%). All in all, expectedly, this catches less things overall, but all the motivational cases are still caught, so all good.
2020-08-29 15:42:38 +08:00
// so we shouldn't just compare ranges of incoming blocks/values.
// If both PHI's are in the same basic block, which is the most interesting
// case, we know they must have identical predecessor list,
// so we only need to check the incoming values.
if (thisPHI->getParent() == otherPHI->getParent()) {
return all_of(thisPHI->blocks(), [thisPHI, otherPHI](BasicBlock *PredBB) {
return thisPHI->getIncomingValueForBlock(PredBB) ==
otherPHI->getIncomingValueForBlock(PredBB);
});
}
// Otherwise, let's just naively compare operands/blocks.
return std::equal(op_begin(), op_end(), I->op_begin()) &&
std::equal(thisPHI->block_begin(), thisPHI->block_end(),
Revert "[InstSimplify][EarlyCSE] Try to CSE PHI nodes in the same basic block" This reverts commit 6102310d814ad73eab60a88b21dd70874f7a056f. It appears to cause compilation non-determinism and caused stage3 mismatches.
2020-08-29 07:32:25 +08:00
otherPHI->block_begin());
}
[InstCombine] Take 2: Perform trivial PHI CSE The original take was 6102310d814ad73eab60a88b21dd70874f7a056f, which taught InstSimplify to do that, which seemed better at time, since we got EarlyCSE support for free. However, it was proven that we can not do that there, the simplified-to PHI would not be reachable from the original PHI, and that is not something InstSimplify is allowed to do, as noted in the commit ed90f15efb40d26b5d3ead3bb8e9e284218e0186 that reverted it : > It appears to cause compilation non-determinism and caused stage3 mismatches. However InstCombine already does many different optimizations, so it should be a safe place to do it here. Note that we still can't just compare incoming values ranges, because there is no guarantee that these PHI's we'd simplify to were already re-visited and sorted. However coming up with a test is problematic. Effects on vanilla llvm test-suite + RawSpeed: ``` | statistic name | baseline | proposed | Δ | % | |%| | |----------------------------------------------------|-----------|-----------|-------:|---------:|---------:| | instcombine.NumPHICSEs | 0 | 22228 | 22228 | 0.00% | 0.00% | | asm-printer.EmittedInsts | 7942329 | 7942456 | 127 | 0.00% | 0.00% | | assembler.ObjectBytes | 254295632 | 254313792 | 18160 | 0.01% | 0.01% | | early-cse.NumCSE | 2183283 | 2183272 | -11 | 0.00% | 0.00% | | early-cse.NumSimplify | 550105 | 541842 | -8263 | -1.50% | 1.50% | | instcombine.NumAggregateReconstructionsSimplified | 73 | 4506 | 4433 | 6072.60% | 6072.60% | | instcombine.NumCombined | 3640311 | 3666911 | 26600 | 0.73% | 0.73% | | instcombine.NumDeadInst | 1778204 | 1783318 | 5114 | 0.29% | 0.29% | | instcount.NumCallInst | 1758395 | 1758804 | 409 | 0.02% | 0.02% | | instcount.NumInvokeInst | 59478 | 59502 | 24 | 0.04% | 0.04% | | instcount.NumPHIInst | 330557 | 330549 | -8 | 0.00% | 0.00% | | instcount.TotalBlocks | 1077138 | 1077221 | 83 | 0.01% | 0.01% | | instcount.TotalFuncs | 101442 | 101441 | -1 | 0.00% | 0.00% | | instcount.TotalInsts | 8831946 | 8832611 | 665 | 0.01% | 0.01% | | simplifycfg.NumInvokes | 4300 | 4410 | 110 | 2.56% | 2.56% | | simplifycfg.NumSimpl | 1019813 | 999740 | -20073 | -1.97% | 1.97% | ``` So it fires ~22k times, which is less than ~24k the take 1 did. It allows foldAggregateConstructionIntoAggregateReuse() to actually work after PHI-of-extractvalue folds did their thing. Previously SimplifyCFG would have done this PHI CSE, of all places. Additionally, allows some more `invoke`->`call` folds to happen (+110, +2.56%). All in all, expectedly, this catches less things overall, but all the motivational cases are still caught, so all good.
2020-08-29 15:42:38 +08:00
// We have two instructions of identical opcode and #operands. Check to see
// if all operands are the same.
if (!std::equal(op_begin(), op_end(), I->op_begin()))
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);
For PR950: This patch removes the SetCC instructions and replaces them with the ICmp and FCmp instructions. The SetCondInst instruction has been removed and been replaced with ICmpInst and FCmpInst. llvm-svn: 32751
2006-12-23 14:05:41 +08:00
}
NFC: keep comment up to date MergeFunctions was refactored a while ago, and Instruction.cpp's comments went out of sync. The content did as well, will fix later. llvm-svn: 266007
2016-04-12 06:30:37 +08:00
// Keep this in sync with FunctionComparator::cmpOperations in
Give Instruction::isSameOperationAs a corresponding comment to note the relationship with MergeFunctions.cpp's isEquivalentOperation, and make a trivial code reordering so that the two functions are easier to compare. Fix the name of Instruction::isSameOperationAs in MergeFunction.cpp's isEquivalentOperation's comment, and fix a nearby 80-column violation. llvm-svn: 73241
2009-06-13 03:03:05 +08:00
// lib/Transforms/IPO/MergeFunctions.cpp.
Refactor operation equivalence checking in BBVectorize by extending Instruction::isSameOperationAs. Maintaining this kind of checking in different places is dangerous, extending Instruction::isSameOperationAs consolidates this logic into one place. Here I've added an optional flags parameter and two flags that are important for vectorization: CompareIgnoringAlignment and CompareUsingScalarTypes. llvm-svn: 159329
2012-06-28 13:42:26 +08:00
bool Instruction::isSameOperationAs(const Instruction *I,
unsigned flags) const {
bool IgnoreAlignment = flags & CompareIgnoringAlignment;
bool UseScalarTypes = flags & CompareUsingScalarTypes;
Give Instruction::isSameOperationAs a corresponding comment to note the relationship with MergeFunctions.cpp's isEquivalentOperation, and make a trivial code reordering so that the two functions are easier to compare. Fix the name of Instruction::isSameOperationAs in MergeFunction.cpp's isEquivalentOperation's comment, and fix a nearby 80-column violation. llvm-svn: 73241
2009-06-13 03:03:05 +08:00
if (getOpcode() != I->getOpcode() ||
getNumOperands() != I->getNumOperands() ||
Refactor operation equivalence checking in BBVectorize by extending Instruction::isSameOperationAs. Maintaining this kind of checking in different places is dangerous, extending Instruction::isSameOperationAs consolidates this logic into one place. Here I've added an optional flags parameter and two flags that are important for vectorization: CompareIgnoringAlignment and CompareUsingScalarTypes. llvm-svn: 159329
2012-06-28 13:42:26 +08:00
(UseScalarTypes ?
getType()->getScalarType() != I->getType()->getScalarType() :
getType() != I->getType()))
For PR950: This patch removes the SetCC instructions and replaces them with the ICmp and FCmp instructions. The SetCondInst instruction has been removed and been replaced with ICmpInst and FCmpInst. llvm-svn: 32751
2006-12-23 14:05:41 +08:00
return false;
// We have two instructions of identical opcode and #operands. Check to see
// if all operands are the same type
for (unsigned i = 0, e = getNumOperands(); i != e; ++i)
Refactor operation equivalence checking in BBVectorize by extending Instruction::isSameOperationAs. Maintaining this kind of checking in different places is dangerous, extending Instruction::isSameOperationAs consolidates this logic into one place. Here I've added an optional flags parameter and two flags that are important for vectorization: CompareIgnoringAlignment and CompareUsingScalarTypes. llvm-svn: 159329
2012-06-28 13:42:26 +08:00
if (UseScalarTypes ?
getOperand(i)->getType()->getScalarType() !=
I->getOperand(i)->getType()->getScalarType() :
getOperand(i)->getType() != I->getOperand(i)->getType())
For PR950: This patch removes the SetCC instructions and replaces them with the ICmp and FCmp instructions. The SetCondInst instruction has been removed and been replaced with ICmpInst and FCmpInst. llvm-svn: 32751
2006-12-23 14:05:41 +08:00
return false;
Factor out comparison of Instruction "special" states. No functional change. llvm-svn: 209688
2014-05-28 05:35:46 +08:00
return haveSameSpecialState(this, I, IgnoreAlignment);
Add method llvm-svn: 18368
2004-11-30 10:51:53 +08:00
}
add a handy helper method to instruction, useful for determining whether it is used outside of some block. This can be used to see if there are any non-local references, for example. llvm-svn: 50004
2008-04-21 06:11:30 +08:00
bool Instruction::isUsedOutsideOfBlock(const BasicBlock *BB) const {
[C++11] Add range based accessors for the Use-Def chain of a Value. This requires a number of steps. 1) Move value_use_iterator into the Value class as an implementation detail 2) Change it to actually be a *Use* iterator rather than a *User* iterator. 3) Add an adaptor which is a User iterator that always looks through the Use to the User. 4) Wrap these in Value::use_iterator and Value::user_iterator typedefs. 5) Add the range adaptors as Value::uses() and Value::users(). 6) Update *all* of the callers to correctly distinguish between whether they wanted a use_iterator (and to explicitly dig out the User when needed), or a user_iterator which makes the Use itself totally opaque. Because #6 requires churning essentially everything that walked the Use-Def chains, I went ahead and added all of the range adaptors and switched them to range-based loops where appropriate. Also because the renaming requires at least churning every line of code, it didn't make any sense to split these up into multiple commits -- all of which would touch all of the same lies of code. The result is still not quite optimal. The Value::use_iterator is a nice regular iterator, but Value::user_iterator is an iterator over User*s rather than over the User objects themselves. As a consequence, it fits a bit awkwardly into the range-based world and it has the weird extra-dereferencing 'operator->' that so many of our iterators have. I think this could be fixed by providing something which transforms a range of T&s into a range of T*s, but that *can* be separated into another patch, and it isn't yet 100% clear whether this is the right move. However, this change gets us most of the benefit and cleans up a substantial amount of code around Use and User. =] llvm-svn: 203364
2014-03-09 11:16:01 +08:00
for (const Use &U : uses()) {
add a handy helper method to instruction, useful for determining whether it is used outside of some block. This can be used to see if there are any non-local references, for example. llvm-svn: 50004
2008-04-21 06:11:30 +08:00
// PHI nodes uses values in the corresponding predecessor block. For other
// instructions, just check to see whether the parent of the use matches up.
[C++11] Add range based accessors for the Use-Def chain of a Value. This requires a number of steps. 1) Move value_use_iterator into the Value class as an implementation detail 2) Change it to actually be a *Use* iterator rather than a *User* iterator. 3) Add an adaptor which is a User iterator that always looks through the Use to the User. 4) Wrap these in Value::use_iterator and Value::user_iterator typedefs. 5) Add the range adaptors as Value::uses() and Value::users(). 6) Update *all* of the callers to correctly distinguish between whether they wanted a use_iterator (and to explicitly dig out the User when needed), or a user_iterator which makes the Use itself totally opaque. Because #6 requires churning essentially everything that walked the Use-Def chains, I went ahead and added all of the range adaptors and switched them to range-based loops where appropriate. Also because the renaming requires at least churning every line of code, it didn't make any sense to split these up into multiple commits -- all of which would touch all of the same lies of code. The result is still not quite optimal. The Value::use_iterator is a nice regular iterator, but Value::user_iterator is an iterator over User*s rather than over the User objects themselves. As a consequence, it fits a bit awkwardly into the range-based world and it has the weird extra-dereferencing 'operator->' that so many of our iterators have. I think this could be fixed by providing something which transforms a range of T&s into a range of T*s, but that *can* be separated into another patch, and it isn't yet 100% clear whether this is the right move. However, this change gets us most of the benefit and cleans up a substantial amount of code around Use and User. =] llvm-svn: 203364
2014-03-09 11:16:01 +08:00
const Instruction *I = cast<Instruction>(U.getUser());
const PHINode *PN = dyn_cast<PHINode>(I);
[C++11] More 'nullptr' conversion or in some cases just using a boolean check instead of comparing to nullptr. llvm-svn: 205831
2014-04-09 14:08:46 +08:00
if (!PN) {
[C++11] Add range based accessors for the Use-Def chain of a Value. This requires a number of steps. 1) Move value_use_iterator into the Value class as an implementation detail 2) Change it to actually be a *Use* iterator rather than a *User* iterator. 3) Add an adaptor which is a User iterator that always looks through the Use to the User. 4) Wrap these in Value::use_iterator and Value::user_iterator typedefs. 5) Add the range adaptors as Value::uses() and Value::users(). 6) Update *all* of the callers to correctly distinguish between whether they wanted a use_iterator (and to explicitly dig out the User when needed), or a user_iterator which makes the Use itself totally opaque. Because #6 requires churning essentially everything that walked the Use-Def chains, I went ahead and added all of the range adaptors and switched them to range-based loops where appropriate. Also because the renaming requires at least churning every line of code, it didn't make any sense to split these up into multiple commits -- all of which would touch all of the same lies of code. The result is still not quite optimal. The Value::use_iterator is a nice regular iterator, but Value::user_iterator is an iterator over User*s rather than over the User objects themselves. As a consequence, it fits a bit awkwardly into the range-based world and it has the weird extra-dereferencing 'operator->' that so many of our iterators have. I think this could be fixed by providing something which transforms a range of T&s into a range of T*s, but that *can* be separated into another patch, and it isn't yet 100% clear whether this is the right move. However, this change gets us most of the benefit and cleans up a substantial amount of code around Use and User. =] llvm-svn: 203364
2014-03-09 11:16:01 +08:00
if (I->getParent() != BB)
add a handy helper method to instruction, useful for determining whether it is used outside of some block. This can be used to see if there are any non-local references, for example. llvm-svn: 50004
2008-04-21 06:11:30 +08:00
return true;
continue;
}
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
[C++11] Add range based accessors for the Use-Def chain of a Value. This requires a number of steps. 1) Move value_use_iterator into the Value class as an implementation detail 2) Change it to actually be a *Use* iterator rather than a *User* iterator. 3) Add an adaptor which is a User iterator that always looks through the Use to the User. 4) Wrap these in Value::use_iterator and Value::user_iterator typedefs. 5) Add the range adaptors as Value::uses() and Value::users(). 6) Update *all* of the callers to correctly distinguish between whether they wanted a use_iterator (and to explicitly dig out the User when needed), or a user_iterator which makes the Use itself totally opaque. Because #6 requires churning essentially everything that walked the Use-Def chains, I went ahead and added all of the range adaptors and switched them to range-based loops where appropriate. Also because the renaming requires at least churning every line of code, it didn't make any sense to split these up into multiple commits -- all of which would touch all of the same lies of code. The result is still not quite optimal. The Value::use_iterator is a nice regular iterator, but Value::user_iterator is an iterator over User*s rather than over the User objects themselves. As a consequence, it fits a bit awkwardly into the range-based world and it has the weird extra-dereferencing 'operator->' that so many of our iterators have. I think this could be fixed by providing something which transforms a range of T&s into a range of T*s, but that *can* be separated into another patch, and it isn't yet 100% clear whether this is the right move. However, this change gets us most of the benefit and cleans up a substantial amount of code around Use and User. =] llvm-svn: 203364
2014-03-09 11:16:01 +08:00
if (PN->getIncomingBlock(U) != BB)
add a handy helper method to instruction, useful for determining whether it is used outside of some block. This can be used to see if there are any non-local references, for example. llvm-svn: 50004
2008-04-21 06:11:30 +08:00
return true;
}
Tabs -> spaces, and remove trailing whitespace. llvm-svn: 82355
2009-09-20 10:20:51 +08:00
return false;
add a handy helper method to instruction, useful for determining whether it is used outside of some block. This can be used to see if there are any non-local references, for example. llvm-svn: 50004
2008-04-21 06:11:30 +08:00
}
add a new Instruction::mayReadFromMemory predicate, make Instruction::mayWriteToMemory stronger for invokes. llvm-svn: 50858
2008-05-09 01:16:51 +08:00
bool Instruction::mayReadFromMemory() const {
switch (getOpcode()) {
default: return false;
case Instruction::VAArg:
conservatively say that volatile stores read memory. llvm-svn: 50872
2008-05-09 05:58:49 +08:00
case Instruction::Load:
Misc mid-level changes for new 'fence' instruction. llvm-svn: 136205
2011-07-27 09:08:30 +08:00
case Instruction::Fence: // FIXME: refine definition of mayReadFromMemory
Misc optimizer+codegen work for 'cmpxchg' and 'atomicrmw'. They appear to be working on x86 (at least for trivial testcases); other architectures will need more work so that they actually emit the appropriate instructions for orderings stricter than 'monotonic'. (As far as I can tell, the ARM, PPC, Mips, and Alpha backends need such changes.) llvm-svn: 136457
2011-07-29 11:05:32 +08:00
case Instruction::AtomicCmpXchg:
case Instruction::AtomicRMW:
[IR] Conservatively mark 'catchpad' as accessing memory The exact semantics of 'catchpad' are really in the hands of the personality routine so we shouldn't assume that they have no side effects. llvm-svn: 247322
2015-09-11 02:50:09 +08:00
case Instruction::CatchPad:
New EH representation for MSVC compatibility This introduces new instructions neccessary to implement MSVC-compatible exception handling support. Most of the middle-end and none of the back-end haven't been audited or updated to take them into account. Differential Revision: http://reviews.llvm.org/D11097 llvm-svn: 243766
2015-08-01 01:58:14 +08:00
case Instruction::CatchRet:
add a new Instruction::mayReadFromMemory predicate, make Instruction::mayWriteToMemory stronger for invokes. llvm-svn: 50858
2008-05-09 01:16:51 +08:00
return true;
case Instruction::Call:
case Instruction::Invoke:
Implementation of asm-goto support in LLVM This patch accompanies the RFC posted here: http://lists.llvm.org/pipermail/llvm-dev/2018-October/127239.html This patch adds a new CallBr IR instruction to support asm-goto inline assembly like gcc as used by the linux kernel. This instruction is both a call instruction and a terminator instruction with multiple successors. Only inline assembly usage is supported today. This also adds a new INLINEASM_BR opcode to SelectionDAG and MachineIR to represent an INLINEASM block that is also considered a terminator instruction. There will likely be more bug fixes and optimizations to follow this, but we felt it had reached a point where we would like to switch to an incremental development model. Patch by Craig Topper, Alexander Ivchenko, Mikhail Dvoretckii Differential Revision: https://reviews.llvm.org/D53765 llvm-svn: 353563
2019-02-09 04:48:56 +08:00
case Instruction::CallBr:
[IR] Fix mayReadFromMemory() for writeonly calls Current implementation of Instruction::mayReadFromMemory() returns !doesNotAccessMemory() which is !ReadNone. This does not take into account that the writeonly attribute also indicates that the call does not read from memory. The patch changes the predicate to !doesNotReadMemory() that reflects the intended behavior. Differential Revision: https://reviews.llvm.org/D69086 llvm-svn: 375389
2019-10-21 14:52:08 +08:00
return !cast<CallBase>(this)->doesNotReadMemory();
conservatively say that volatile stores read memory. llvm-svn: 50872
2008-05-09 05:58:49 +08:00
case Instruction::Store:
Fix predicates methods on Instruction to handle atomic load/store correctly. llvm-svn: 137652
2011-08-16 05:00:18 +08:00
return !cast<StoreInst>(this)->isUnordered();
add a new Instruction::mayReadFromMemory predicate, make Instruction::mayWriteToMemory stronger for invokes. llvm-svn: 50858
2008-05-09 01:16:51 +08:00
}
}
add a handy helper method to instruction, useful for determining whether it is used outside of some block. This can be used to see if there are any non-local references, for example. llvm-svn: 50004
2008-04-21 06:11:30 +08:00
make mayWriteToMemory a non-virtual function llvm-svn: 34334
2007-02-16 07:15:00 +08:00
bool Instruction::mayWriteToMemory() const {
switch (getOpcode()) {
default: return false;
Misc mid-level changes for new 'fence' instruction. llvm-svn: 136205
2011-07-27 09:08:30 +08:00
case Instruction::Fence: // FIXME: refine definition of mayWriteToMemory
Rather than having special rules like "intrinsics cannot throw exceptions", just mark intrinsics with the nounwind attribute. Likewise, mark intrinsics as readnone/readonly and get rid of special aliasing logic (which didn't use anything more than this anyway). llvm-svn: 44544
2007-12-04 04:06:50 +08:00
case Instruction::Store:
make mayWriteToMemory a non-virtual function llvm-svn: 34334
2007-02-16 07:15:00 +08:00
case Instruction::VAArg:
Misc optimizer+codegen work for 'cmpxchg' and 'atomicrmw'. They appear to be working on x86 (at least for trivial testcases); other architectures will need more work so that they actually emit the appropriate instructions for orderings stricter than 'monotonic'. (As far as I can tell, the ARM, PPC, Mips, and Alpha backends need such changes.) llvm-svn: 136457
2011-07-29 11:05:32 +08:00
case Instruction::AtomicCmpXchg:
case Instruction::AtomicRMW:
[IR] Conservatively mark 'catchpad' as accessing memory The exact semantics of 'catchpad' are really in the hands of the personality routine so we shouldn't assume that they have no side effects. llvm-svn: 247322
2015-09-11 02:50:09 +08:00
case Instruction::CatchPad:
New EH representation for MSVC compatibility This introduces new instructions neccessary to implement MSVC-compatible exception handling support. Most of the middle-end and none of the back-end haven't been audited or updated to take them into account. Differential Revision: http://reviews.llvm.org/D11097 llvm-svn: 243766
2015-08-01 01:58:14 +08:00
case Instruction::CatchRet:
make mayWriteToMemory a non-virtual function llvm-svn: 34334
2007-02-16 07:15:00 +08:00
return true;
case Instruction::Call:
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:
Implementation of asm-goto support in LLVM This patch accompanies the RFC posted here: http://lists.llvm.org/pipermail/llvm-dev/2018-October/127239.html This patch adds a new CallBr IR instruction to support asm-goto inline assembly like gcc as used by the linux kernel. This instruction is both a call instruction and a terminator instruction with multiple successors. Only inline assembly usage is supported today. This also adds a new INLINEASM_BR opcode to SelectionDAG and MachineIR to represent an INLINEASM block that is also considered a terminator instruction. There will likely be more bug fixes and optimizations to follow this, but we felt it had reached a point where we would like to switch to an incremental development model. Patch by Craig Topper, Alexander Ivchenko, Mikhail Dvoretckii Differential Revision: https://reviews.llvm.org/D53765 llvm-svn: 353563
2019-02-09 04:48:56 +08:00
case Instruction::CallBr:
[IR] Use CallBase to reduce code duplication. NFC Noticed in the asm-goto patch. Callbr needs to go here too. One cast and call is better than 3. Differential Revision: https://reviews.llvm.org/D57295 llvm-svn: 352563
2019-01-30 07:31:54 +08:00
return !cast<CallBase>(this)->onlyReadsMemory();
make mayWriteToMemory a non-virtual function llvm-svn: 34334
2007-02-16 07:15:00 +08:00
case Instruction::Load:
Fix predicates methods on Instruction to handle atomic load/store correctly. llvm-svn: 137652
2011-08-16 05:00:18 +08:00
return !cast<LoadInst>(this)->isUnordered();
make mayWriteToMemory a non-virtual function llvm-svn: 34334
2007-02-16 07:15:00 +08:00
}
}
New isAssociative/isCommutative inspection methods, graciously contributed by Casey Carter. llvm-svn: 4459
2002-10-31 12:14:01 +08:00
Refactor AtomicExpandPass and add a generic isAtomic() method to Instruction Summary: Split shouldExpandAtomicInIR() into different versions for Stores/Loads/RMWs/CmpXchgs. Makes runOnFunction cleaner (no more redundant checking/casting), and will help moving the X86 backend to this pass. This requires a way of easily detecting which instructions are atomic. I followed the pattern of mayReadFromMemory, mayWriteOrReadMemory, etc.. in making isAtomic() a method of Instruction implemented by a switch on the opcodes. Test Plan: make check Reviewers: jfb Subscribers: mcrosier, llvm-commits Differential Revision: http://reviews.llvm.org/D5035 llvm-svn: 217080
2014-09-04 05:29:59 +08:00
bool Instruction::isAtomic() const {
switch (getOpcode()) {
default:
return false;
case Instruction::AtomicCmpXchg:
case Instruction::AtomicRMW:
case Instruction::Fence:
return true;
case Instruction::Load:
NFC: make AtomicOrdering an enum class Summary: In the context of http://wg21.link/lwg2445 C++ uses the concept of 'stronger' ordering but doesn't define it properly. This should be fixed in C++17 barring a small question that's still open. The code currently plays fast and loose with the AtomicOrdering enum. Using an enum class is one step towards tightening things. I later also want to tighten related enums, such as clang's AtomicOrderingKind (which should be shared with LLVM as a 'C++ ABI' enum). This change touches a few lines of code which can be improved later, I'd like to keep it as NFC for now as it's already quite complex. I have related changes for clang. As a follow-up I'll add: bool operator<(AtomicOrdering, AtomicOrdering) = delete; bool operator>(AtomicOrdering, AtomicOrdering) = delete; bool operator<=(AtomicOrdering, AtomicOrdering) = delete; bool operator>=(AtomicOrdering, AtomicOrdering) = delete; This is separate so that clang and LLVM changes don't need to be in sync. Reviewers: jyknight, reames Subscribers: jyknight, llvm-commits Differential Revision: http://reviews.llvm.org/D18775 llvm-svn: 265602
2016-04-07 05:19:33 +08:00
return cast<LoadInst>(this)->getOrdering() != AtomicOrdering::NotAtomic;
Refactor AtomicExpandPass and add a generic isAtomic() method to Instruction Summary: Split shouldExpandAtomicInIR() into different versions for Stores/Loads/RMWs/CmpXchgs. Makes runOnFunction cleaner (no more redundant checking/casting), and will help moving the X86 backend to this pass. This requires a way of easily detecting which instructions are atomic. I followed the pattern of mayReadFromMemory, mayWriteOrReadMemory, etc.. in making isAtomic() a method of Instruction implemented by a switch on the opcodes. Test Plan: make check Reviewers: jfb Subscribers: mcrosier, llvm-commits Differential Revision: http://reviews.llvm.org/D5035 llvm-svn: 217080
2014-09-04 05:29:59 +08:00
case Instruction::Store:
NFC: make AtomicOrdering an enum class Summary: In the context of http://wg21.link/lwg2445 C++ uses the concept of 'stronger' ordering but doesn't define it properly. This should be fixed in C++17 barring a small question that's still open. The code currently plays fast and loose with the AtomicOrdering enum. Using an enum class is one step towards tightening things. I later also want to tighten related enums, such as clang's AtomicOrderingKind (which should be shared with LLVM as a 'C++ ABI' enum). This change touches a few lines of code which can be improved later, I'd like to keep it as NFC for now as it's already quite complex. I have related changes for clang. As a follow-up I'll add: bool operator<(AtomicOrdering, AtomicOrdering) = delete; bool operator>(AtomicOrdering, AtomicOrdering) = delete; bool operator<=(AtomicOrdering, AtomicOrdering) = delete; bool operator>=(AtomicOrdering, AtomicOrdering) = delete; This is separate so that clang and LLVM changes don't need to be in sync. Reviewers: jyknight, reames Subscribers: jyknight, llvm-commits Differential Revision: http://reviews.llvm.org/D18775 llvm-svn: 265602
2016-04-07 05:19:33 +08:00
return cast<StoreInst>(this)->getOrdering() != AtomicOrdering::NotAtomic;
Refactor AtomicExpandPass and add a generic isAtomic() method to Instruction Summary: Split shouldExpandAtomicInIR() into different versions for Stores/Loads/RMWs/CmpXchgs. Makes runOnFunction cleaner (no more redundant checking/casting), and will help moving the X86 backend to this pass. This requires a way of easily detecting which instructions are atomic. I followed the pattern of mayReadFromMemory, mayWriteOrReadMemory, etc.. in making isAtomic() a method of Instruction implemented by a switch on the opcodes. Test Plan: make check Reviewers: jfb Subscribers: mcrosier, llvm-commits Differential Revision: http://reviews.llvm.org/D5035 llvm-svn: 217080
2014-09-04 05:29:59 +08:00
}
}
[Atomic] Remove IsStore/IsLoad in the interface, and pass the instruction instead. NFC. Now both emitLeadingFence and emitTrailingFence take the instruction itself, instead of taking IsLoad/IsStore pairs. Instruction::mayReadFromMemory and Instrucion::mayWriteToMemory are used for determining those two booleans. The instruction argument is also useful for later D32763, in emitTrailingFence. For emitLeadingFence, it seems to have cleaner interface with the proposed change. Differential Revision: https://reviews.llvm.org/D32762 llvm-svn: 302539
2017-05-09 23:27:17 +08:00
bool Instruction::hasAtomicLoad() const {
assert(isAtomic());
switch (getOpcode()) {
default:
return false;
case Instruction::AtomicCmpXchg:
case Instruction::AtomicRMW:
case Instruction::Load:
return true;
}
}
bool Instruction::hasAtomicStore() const {
assert(isAtomic());
switch (getOpcode()) {
default:
return false;
case Instruction::AtomicCmpXchg:
case Instruction::AtomicRMW:
case Instruction::Store:
return true;
}
}
Allow readonly functions to unwind exceptions. Teach the optimizers about this. For example, a readonly function with no uses cannot be removed unless it is also marked nounwind. llvm-svn: 71071
2009-05-06 14:49:50 +08:00
bool Instruction::mayThrow() const {
if (const CallInst *CI = dyn_cast<CallInst>(this))
return !CI->doesNotThrow();
New EH representation for MSVC compatibility This introduces new instructions neccessary to implement MSVC-compatible exception handling support. Most of the middle-end and none of the back-end haven't been audited or updated to take them into account. Differential Revision: http://reviews.llvm.org/D11097 llvm-svn: 243766
2015-08-01 01:58:14 +08:00
if (const auto *CRI = dyn_cast<CleanupReturnInst>(this))
return CRI->unwindsToCaller();
[IR] Reformulate LLVM's EH funclet IR While we have successfully implemented a funclet-oriented EH scheme on top of LLVM IR, our scheme has some notable deficiencies: - catchendpad and cleanupendpad are necessary in the current design but they are difficult to explain to others, even to seasoned LLVM experts. - catchendpad and cleanupendpad are optimization barriers. They cannot be split and force all potentially throwing call-sites to be invokes. This has a noticable effect on the quality of our code generation. - catchpad, while similar in some aspects to invoke, is fairly awkward. It is unsplittable, starts a funclet, and has control flow to other funclets. - The nesting relationship between funclets is currently a property of control flow edges. Because of this, we are forced to carefully analyze the flow graph to see if there might potentially exist illegal nesting among funclets. While we have logic to clone funclets when they are illegally nested, it would be nicer if we had a representation which forbade them upfront. Let's clean this up a bit by doing the following: - Instead, make catchpad more like cleanuppad and landingpad: no control flow, just a bunch of simple operands; catchpad would be splittable. - Introduce catchswitch, a control flow instruction designed to model the constraints of funclet oriented EH. - Make funclet scoping explicit by having funclet instructions consume the token produced by the funclet which contains them. - Remove catchendpad and cleanupendpad. Their presence can be inferred implicitly using coloring information. N.B. The state numbering code for the CLR has been updated but the veracity of it's output cannot be spoken for. An expert should take a look to make sure the results are reasonable. Reviewers: rnk, JosephTremoulet, andrew.w.kaylor Differential Revision: http://reviews.llvm.org/D15139 llvm-svn: 255422
2015-12-12 13:38:55 +08:00
if (const auto *CatchSwitch = dyn_cast<CatchSwitchInst>(this))
return CatchSwitch->unwindsToCaller();
The resume instruction may throw. Return 'true' in this case. llvm-svn: 137757
2011-08-17 05:15:50 +08:00
return isa<ResumeInst>(this);
Allow readonly functions to unwind exceptions. Teach the optimizers about this. For example, a readonly function with no uses cannot be removed unless it is also marked nounwind. llvm-svn: 71071
2009-05-06 14:49:50 +08:00
}
[IPSCCP] Remove calls without side effects Summary: When performing constant propagation for call instructions we have historically replaced all uses of the return from a call, but not removed the call itself. This is required for correctness if the calls have side effects, however the compiler should be able to safely remove calls that don't have side effects. This allows the compiler to completely fold away calls to functions that have no side effects if the inputs are constant and the output can be determined at compile time. Reviewers: davide, sanjoy, bruno, dberlin Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D38856 llvm-svn: 322125
2018-01-10 05:58:46 +08:00
bool Instruction::isSafeToRemove() const {
return (!isa<CallInst>(this) || !this->mayHaveSideEffects()) &&
[IR] Replace `isa<TerminatorInst>` with `isTerminator()`. This is a bit awkward in a handful of places where we didn't even have an instruction and now we have to see if we can build one. But on the whole, this seems like a win and at worst a reasonable cost for removing `TerminatorInst`. All of this is part of the removal of `TerminatorInst` from the `Instruction` type hierarchy. llvm-svn: 340701
2018-08-26 17:51:22 +08:00
!this->isTerminator();
[IPSCCP] Remove calls without side effects Summary: When performing constant propagation for call instructions we have historically replaced all uses of the return from a call, but not removed the call itself. This is required for correctness if the calls have side effects, however the compiler should be able to safely remove calls that don't have side effects. This allows the compiler to completely fold away calls to functions that have no side effects if the inputs are constant and the output can be determined at compile time. Reviewers: davide, sanjoy, bruno, dberlin Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D38856 llvm-svn: 322125
2018-01-10 05:58:46 +08:00
}
[IR] Add Instruction::isLifetimeStartOrEnd, NFC Instruction::isLifetimeStartOrEnd() checks whether an Instruction is an llvm.lifetime.start or an llvm.lifetime.end intrinsic. This was suggested as a cleanup in D55967. Differential Revision: https://reviews.llvm.org/D56019 llvm-svn: 349964
2018-12-22 05:49:40 +08:00
bool Instruction::isLifetimeStartOrEnd() const {
auto II = dyn_cast<IntrinsicInst>(this);
if (!II)
return false;
Intrinsic::ID ID = II->getIntrinsicID();
return ID == Intrinsic::lifetime_start || ID == Intrinsic::lifetime_end;
}
[IR] Introduce helpers to skip debug instructions (NFC) This patch introduces two helpers to make it easier to ignore debug intrinsics: - Instruction::getNextNonDebugInstruction() This is just like Instruction::getNextNode(), except that it skips debug info. - skipDebugInfo(BasicBlock::iterator) A free function which advances a BasicBlock iterator past any debug info. This is a no-op when the iterator already points to a non-debug instruction. Part of: llvm.org/PR37728 Related to: https://reviews.llvm.org/D47874 Differential Revision: https://reviews.llvm.org/D48305 llvm-svn: 335083
2018-06-20 07:42:17 +08:00
const Instruction *Instruction::getNextNonDebugInstruction() const {
for (const Instruction *I = getNextNode(); I; I = I->getNextNode())
if (!isa<DbgInfoIntrinsic>(I))
return I;
return nullptr;
}
[DebugInfo][Dexter] Unreachable line stepped onto after SimplifyCFG. In SimplifyCFG when given a conditional branch that goes to BB1 and BB2, the hoisted common terminator instruction in the two blocks, caused debug line records associated with subsequent select instructions to become ambiguous. It causes the debugger to display unreachable source lines. Differential Revision: https://reviews.llvm.org/D53390 llvm-svn: 346481
2018-11-09 17:42:10 +08:00
const Instruction *Instruction::getPrevNonDebugInstruction() const {
for (const Instruction *I = getPrevNode(); I; I = I->getPrevNode())
if (!isa<DbgInfoIntrinsic>(I))
return I;
return nullptr;
}
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:
[InstCombine] Enable more reassociations using FMF 'reassoc' + 'nsz' Reassociation of math ops in some contexts (especially vector contexts) has generally only been happening when the 'fast' FMF was set. This enables reassoication when only the finer grained controls 'reassoc' and 'nsz' are set. Differential Revision: https://reviews.llvm.org/D47335 llvm-svn: 333221
2018-05-25 04:16:43 +08:00
return cast<FPMathOperator>(this)->hasAllowReassoc() &&
cast<FPMathOperator>(this)->hasNoSignedZeros();
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
default:
return false;
}
}
[IR] Begin removal of TerminatorInst by removing successor manipulation. The core get and set routines move to the `Instruction` class. These routines are only valid to call on instructions which are terminators. The iterator and *generic* range based access move to `CFG.h` where all the other generic successor and predecessor access lives. While moving the iterator here, simplify it using the iterator utilities LLVM provides and updates coding style as much as reasonable. The APIs remain pointer-heavy when they could better use references, and retain the odd behavior of `operator*` and `operator->` that is common in LLVM iterators. Adjusting this API, if desired, should be a follow-up step. Non-generic range iteration is added for the two instructions where there is an especially easy mechanism and where there was code attempting to use the range accessor from a specific subclass: `indirectbr` and `br`. In both cases, the successors are contiguous operands and can be easily iterated via the operand list. This is the first major patch in removing the `TerminatorInst` type from the IR's instruction type hierarchy. This change was discussed in an RFC here and was pretty clearly positive: http://lists.llvm.org/pipermail/llvm-dev/2018-May/123407.html There will be a series of much more mechanical changes following this one to complete this move. Differential Revision: https://reviews.llvm.org/D47467 llvm-svn: 340698
2018-08-26 16:41:15 +08:00
unsigned Instruction::getNumSuccessors() const {
switch (getOpcode()) {
#define HANDLE_TERM_INST(N, OPC, CLASS) \
case Instruction::OPC: \
return static_cast<const CLASS *>(this)->getNumSuccessors();
#include "llvm/IR/Instruction.def"
default:
break;
}
llvm_unreachable("not a terminator");
}
BasicBlock *Instruction::getSuccessor(unsigned idx) const {
switch (getOpcode()) {
#define HANDLE_TERM_INST(N, OPC, CLASS) \
case Instruction::OPC: \
return static_cast<const CLASS *>(this)->getSuccessor(idx);
#include "llvm/IR/Instruction.def"
default:
break;
}
llvm_unreachable("not a terminator");
}
void Instruction::setSuccessor(unsigned idx, BasicBlock *B) {
switch (getOpcode()) {
#define HANDLE_TERM_INST(N, OPC, CLASS) \
case Instruction::OPC: \
return static_cast<CLASS *>(this)->setSuccessor(idx, B);
#include "llvm/IR/Instruction.def"
default:
break;
}
llvm_unreachable("not a terminator");
}
[NFC] Instruction: introduce replaceSuccessorWith() function, use it Summary: There is `Instruction::getNumSuccessors()`, `Instruction::getSuccessor()` and `Instruction::setSuccessor()`, but no function to replace every specified `BasicBlock*` successor with some other specified `BasicBlock*`. I've found one place where it should clearly be used. Reviewers: chandlerc, craig.topper, spatel, danielcdh Reviewed By: craig.topper Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D61010 llvm-svn: 359994
2019-05-06 02:59:22 +08:00
void Instruction::replaceSuccessorWith(BasicBlock *OldBB, BasicBlock *NewBB) {
for (unsigned Idx = 0, NumSuccessors = Instruction::getNumSuccessors();
Idx != NumSuccessors; ++Idx)
if (getSuccessor(Idx) == OldBB)
setSuccessor(Idx, NewBB);
}
Devirtualize Instruction::clone_impl llvm-svn: 240588
2015-06-25 04:22:23 +08:00
Instruction *Instruction::cloneImpl() const {
llvm_unreachable("Subclass of Instruction failed to implement cloneImpl");
}
[Profile] refactor meta data copying/swapping code Differential Revision: http://reviews.llvm.org/D23619 llvm-svn: 279523
2016-08-23 23:39:03 +08:00
void Instruction::swapProfMetadata() {
MDNode *ProfileData = getMetadata(LLVMContext::MD_prof);
if (!ProfileData || ProfileData->getNumOperands() != 3 ||
!isa<MDString>(ProfileData->getOperand(0)))
return;
MDString *MDName = cast<MDString>(ProfileData->getOperand(0));
if (MDName->getString() != "branch_weights")
return;
// The first operand is the name. Fetch them backwards and build a new one.
Metadata *Ops[] = {ProfileData->getOperand(0), ProfileData->getOperand(2),
ProfileData->getOperand(1)};
setMetadata(LLVMContext::MD_prof,
MDNode::get(ProfileData->getContext(), Ops));
}
void Instruction::copyMetadata(const Instruction &SrcInst,
ArrayRef<unsigned> WL) {
if (!SrcInst.hasMetadata())
return;
DenseSet<unsigned> WLS;
for (unsigned M : WL)
WLS.insert(M);
// Otherwise, enumerate and copy over metadata from the old instruction to the
// new one.
SmallVector<std::pair<unsigned, MDNode *>, 4> TheMDs;
SrcInst.getAllMetadataOtherThanDebugLoc(TheMDs);
for (const auto &MD : TheMDs) {
if (WL.empty() || WLS.count(MD.first))
setMetadata(MD.first, MD.second);
}
if (WL.empty() || WLS.count(LLVMContext::MD_dbg))
setDebugLoc(SrcInst.getDebugLoc());
}
Factor out redundancy from clone() implementations. llvm-svn: 85327
2009-10-28 06:16:29 +08:00
Instruction *Instruction::clone() const {
Devirtualize Instruction::clone_impl llvm-svn: 240588
2015-06-25 04:22:23 +08:00
Instruction *New = nullptr;
switch (getOpcode()) {
default:
llvm_unreachable("Unhandled Opcode.");
#define HANDLE_INST(num, opc, clas) \
case Instruction::opc: \
New = cast<clas>(this)->cloneImpl(); \
break;
#include "llvm/IR/Instruction.def"
#undef HANDLE_INST
}
Factor out redundancy from clone() implementations. llvm-svn: 85327
2009-10-28 06:16:29 +08:00
New->SubclassOptionalData = SubclassOptionalData;
[Profile] refactor meta data copying/swapping code Differential Revision: http://reviews.llvm.org/D23619 llvm-svn: 279523
2016-08-23 23:39:03 +08:00
New->copyMetadata(*this);
Factor out redundancy from clone() implementations. llvm-svn: 85327
2009-10-28 06:16:29 +08:00
return New;
}