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/Attributes.cpp

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

2122 lines
67 KiB
C++
Raw Normal View History

[IR] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC). llvm-svn: 295383
2017-02-17 08:00:09 +08:00
//===- Attributes.cpp - Implement AttributesList --------------------------===//
Split param attr implementation out from Function.cpp into its own file. Don't #include ParameterAttributes.h into any major public header files: just move methods out of line as appropriate. llvm-svn: 45517
2008-01-03 07:42:30 +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
Split param attr implementation out from Function.cpp into its own file. Don't #include ParameterAttributes.h into any major public header files: just move methods out of line as appropriate. llvm-svn: 45517
2008-01-03 07:42:30 +08:00
//
//===----------------------------------------------------------------------===//
//
Remove the AttributeWithIndex class. The AttributeWithIndex class exposed the interior structure of the AttributeSet class. That was gross. Remove it and all of the code that relied upon it. llvm-svn: 173722
2013-01-29 05:55:20 +08:00
// \file
Remove \brief commands from doxygen comments. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46290 llvm-svn: 331272
2018-05-01 23:54:18 +08:00
// This file implements the Attribute, AttributeImpl, AttrBuilder,
Rename AttributeSet to AttributeList Summary: This class is a list of AttributeSetNodes corresponding the function prototype of a call or function declaration. This class used to be called ParamAttrListPtr, then AttrListPtr, then AttributeSet. It is typically accessed by parameter and return value index, so "AttributeList" seems like a more intuitive name. Rename AttributeSetImpl to AttributeListImpl to follow suit. It's useful to rename this class so that we can rename AttributeSetNode to AttributeSet later. AttributeSet is the set of attributes that apply to a single function, argument, or return value. Reviewers: sanjoy, javed.absar, chandlerc, pete Reviewed By: pete Subscribers: pete, jholewinski, arsenm, dschuff, mehdi_amini, jfb, nhaehnle, sbc100, void, llvm-commits Differential Revision: https://reviews.llvm.org/D31102 llvm-svn: 298393
2017-03-22 00:57:19 +08:00
// AttributeListImpl, and AttributeList classes.
Split param attr implementation out from Function.cpp into its own file. Don't #include ParameterAttributes.h into any major public header files: just move methods out of line as appropriate. llvm-svn: 45517
2008-01-03 07:42:30 +08:00
//
//===----------------------------------------------------------------------===//
Sort the remaining #include lines in include/... and lib/.... I did this a long time ago with a janky python script, but now clang-format has built-in support for this. I fed clang-format every line with a #include and let it re-sort things according to the precise LLVM rules for include ordering baked into clang-format these days. I've reverted a number of files where the results of sorting includes isn't healthy. Either places where we have legacy code relying on particular include ordering (where possible, I'll fix these separately) or where we have particular formatting around #include lines that I didn't want to disturb in this patch. This patch is *entirely* mechanical. If you get merge conflicts or anything, just ignore the changes in this patch and run clang-format over your #include lines in the files. Sorry for any noise here, but it is important to keep these things stable. I was seeing an increasing number of patches with irrelevant re-ordering of #include lines because clang-format was used. This patch at least isolates that churn, makes it easy to skip when resolving conflicts, and gets us to a clean baseline (again). llvm-svn: 304787
2017-06-06 19:49:48 +08:00
#include "llvm/IR/Attributes.h"
s/AttributesImpl/AttributeImpl/g This is going to apply to Attribute, not Attributes. llvm-svn: 170631
2012-12-20 09:36:59 +08:00
#include "AttributeImpl.h"
Initial commit for the AttributesImpl class. This opaque class will contain all of the attributes. All attribute queries will go through this object. This object will also be uniqued in the LLVMContext. Currently not used, so no implementation change. llvm-svn: 164722
2012-09-27 05:07:29 +08:00
#include "LLVMContextImpl.h"
[IR] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC). llvm-svn: 295383
2017-02-17 08:00:09 +08:00
#include "llvm/ADT/ArrayRef.h"
#include "llvm/ADT/FoldingSet.h"
#include "llvm/ADT/Optional.h"
Retire llvm::array_endof in favor of non-member std::end. While there make array_lengthof constexpr if we have support for it. llvm-svn: 206112
2014-04-13 00:15:53 +08:00
#include "llvm/ADT/STLExtras.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/SmallVector.h"
Use the new script to sort the includes of every file under lib. Sooooo many of these had incorrect or strange main module includes. I have manually inspected all of these, and fixed the main module include to be the nearest plausible thing I could find. If you own or care about any of these source files, I encourage you to take some time and check that these edits were sensible. I can't have broken anything (I strictly added headers, and reordered them, never removed), but they may not be the headers you'd really like to identify as containing the API being implemented. Many forward declarations and missing includes were added to a header files to allow them to parse cleanly when included first. The main module rule does in fact have its merits. =] llvm-svn: 169131
2012-12-04 00:50:05 +08:00
#include "llvm/ADT/StringExtras.h"
[IR] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC). llvm-svn: 295383
2017-02-17 08:00:09 +08:00
#include "llvm/ADT/StringRef.h"
Avoid including FileSystem.h from MemoryBuffer.h Lots of headers pass around MemoryBuffer objects, but very few open them. Let those that do include FileSystem.h. Saves ~250 includes of Chrono.h & FileSystem.h: $ diff -u thedeps-before.txt thedeps-after.txt | grep '^[-+] ' | sort | uniq -c | sort -nr 254 - ../llvm/include/llvm/Support/FileSystem.h 253 - ../llvm/include/llvm/Support/Chrono.h 237 - ../llvm/include/llvm/Support/NativeFormatting.h 237 - ../llvm/include/llvm/Support/FormatProviders.h 192 - ../llvm/include/llvm/ADT/StringSwitch.h 190 - ../llvm/include/llvm/Support/FormatVariadicDetails.h ... This requires duplicating the file_t typedef, which is unfortunate. I sunk the choice of mapping mode down into the cpp file using variable template specializations instead of class members in headers.
2020-03-01 02:23:54 +08:00
#include "llvm/ADT/StringSwitch.h"
Attributes.cpp - fix include sorting order. NFC.
2020-06-25 19:48:36 +08:00
#include "llvm/ADT/Twine.h"
IWYU for llvm-config.h in llvm, additions. See r331124 for how I made a list of files missing the include. I then ran this Python script: for f in open('filelist.txt'): f = f.strip() fl = open(f).readlines() found = False for i in xrange(len(fl)): p = '#include "llvm/' if not fl[i].startswith(p): continue if fl[i][len(p):] > 'Config': fl.insert(i, '#include "llvm/Config/llvm-config.h"\n') found = True break if not found: print 'not found', f else: open(f, 'w').write(''.join(fl)) and then looked through everything with `svn diff | diffstat -l | xargs -n 1000 gvim -p` and tried to fix include ordering and whatnot. No intended behavior change. llvm-svn: 331184
2018-04-30 22:59:11 +08:00
#include "llvm/Config/llvm-config.h"
[IR] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC). llvm-svn: 295383
2017-02-17 08:00:09 +08:00
#include "llvm/IR/Function.h"
#include "llvm/IR/LLVMContext.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/Type.h"
[IR] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC). llvm-svn: 295383
2017-02-17 08:00:09 +08:00
#include "llvm/Support/Compiler.h"
Change errs() to dbgs(). llvm-svn: 92658
2010-01-05 09:29:58 +08:00
#include "llvm/Support/Debug.h"
[IR] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC). llvm-svn: 295383
2017-02-17 08:00:09 +08:00
#include "llvm/Support/ErrorHandling.h"
#include "llvm/Support/MathExtras.h"
Kill off more cerr/cout uses and prune includes a bit. llvm-svn: 79852
2009-08-23 19:37:21 +08:00
#include "llvm/Support/raw_ostream.h"
Create a new class: AttributeSetNode. This is a helper class for the AttributeSetImpl class. It holds a set of attributes that apply to a single element: function, return type, or parameter. These are uniqued. llvm-svn: 173310
2013-01-24 08:06:56 +08:00
#include <algorithm>
[IR] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC). llvm-svn: 295383
2017-02-17 08:00:09 +08:00
#include <cassert>
[IR] Fix some Clang-tidy modernize-use-using warnings; other minor fixes (NFC). llvm-svn: 303119
2017-05-16 05:57:41 +08:00
#include <climits>
#include <cstddef>
[IR] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC). llvm-svn: 295383
2017-02-17 08:00:09 +08:00
#include <cstdint>
#include <limits>
#include <string>
#include <tuple>
#include <utility>
Split param attr implementation out from Function.cpp into its own file. Don't #include ParameterAttributes.h into any major public header files: just move methods out of line as appropriate. llvm-svn: 45517
2008-01-03 07:42:30 +08:00
using namespace llvm;
Reimplement the parameter attributes support, phase #1. hilights: 1. There is now a "PAListPtr" class, which is a smart pointer around the underlying uniqued parameter attribute list object, and manages its refcount. It is now impossible to mess up the refcount. 2. PAListPtr is now the main interface to the underlying object, and the underlying object is now completely opaque. 3. Implementation details like SmallVector and FoldingSet are now no longer part of the interface. 4. You can create a PAListPtr with an arbitrary sequence of ParamAttrsWithIndex's, no need to make a SmallVector of a specific size (you can just use an array or scalar or vector if you wish). 5. All the client code that had to check for a null pointer before dereferencing the pointer is simplified to just access the PAListPtr directly. 6. The interfaces for adding attrs to a list and removing them is a bit simpler. Phase #2 will rename some stuff (e.g. PAListPtr) and do other less invasive changes. llvm-svn: 48289
2008-03-13 01:45:29 +08:00
//===----------------------------------------------------------------------===//
S'more small non-functional changes in comments and #includes. llvm-svn: 173738
2013-01-29 08:48:16 +08:00
// Attribute Construction Methods
Reimplement the parameter attributes support, phase #1. hilights: 1. There is now a "PAListPtr" class, which is a smart pointer around the underlying uniqued parameter attribute list object, and manages its refcount. It is now impossible to mess up the refcount. 2. PAListPtr is now the main interface to the underlying object, and the underlying object is now completely opaque. 3. Implementation details like SmallVector and FoldingSet are now no longer part of the interface. 4. You can create a PAListPtr with an arbitrary sequence of ParamAttrsWithIndex's, no need to make a SmallVector of a specific size (you can just use an array or scalar or vector if you wish). 5. All the client code that had to check for a null pointer before dereferencing the pointer is simplified to just access the PAListPtr directly. 6. The interfaces for adding attrs to a list and removing them is a bit simpler. Phase #2 will rename some stuff (e.g. PAListPtr) and do other less invasive changes. llvm-svn: 48289
2008-03-13 01:45:29 +08:00
//===----------------------------------------------------------------------===//
I noticed that the trampoline straightening transformation could drop attributes on varargs call arguments. Also, it could generate invalid IR if the transformed call already had the 'nest' attribute somewhere (this can never happen for code coming from llvm-gcc, but it's a theoretical possibility). Fix both problems. llvm-svn: 45973
2008-01-15 03:52:09 +08:00
Add the allocsize attribute to LLVM. `allocsize` is a function attribute that allows users to request that LLVM treat arbitrary functions as allocation functions. This patch makes LLVM accept the `allocsize` attribute, and makes `@llvm.objectsize` recognize said attribute. The review for this was split into two patches for ease of reviewing: D18974 and D14933. As promised on the revisions, I'm landing both patches as a single commit. Differential Revision: http://reviews.llvm.org/D14933 llvm-svn: 266032
2016-04-12 09:05:35 +08:00
// allocsize has two integer arguments, but because they're both 32 bits, we can
// pack them into one 64-bit value, at the cost of making said value
// nonsensical.
//
// In order to do this, we need to reserve one value of the second (optional)
// allocsize argument to signify "not present."
Make some LLVM_CONSTEXPR variables const. NFC. This patch changes LLVM_CONSTEXPR variable declarations to const variable declarations, since LLVM_CONSTEXPR expands to nothing if the current compiler doesn't support constexpr. In all of the changed cases, it looks like the code intended the variable to be const instead of sometimes-constexpr sometimes-not. llvm-svn: 279696
2016-08-25 09:05:08 +08:00
static const unsigned AllocSizeNumElemsNotPresent = -1;
Add the allocsize attribute to LLVM. `allocsize` is a function attribute that allows users to request that LLVM treat arbitrary functions as allocation functions. This patch makes LLVM accept the `allocsize` attribute, and makes `@llvm.objectsize` recognize said attribute. The review for this was split into two patches for ease of reviewing: D18974 and D14933. As promised on the revisions, I'm landing both patches as a single commit. Differential Revision: http://reviews.llvm.org/D14933 llvm-svn: 266032
2016-04-12 09:05:35 +08:00
static uint64_t packAllocSizeArgs(unsigned ElemSizeArg,
const Optional<unsigned> &NumElemsArg) {
assert((!NumElemsArg.hasValue() ||
*NumElemsArg != AllocSizeNumElemsNotPresent) &&
"Attempting to pack a reserved value");
return uint64_t(ElemSizeArg) << 32 |
NumElemsArg.getValueOr(AllocSizeNumElemsNotPresent);
}
static std::pair<unsigned, Optional<unsigned>>
unpackAllocSizeArgs(uint64_t Num) {
unsigned NumElems = Num & std::numeric_limits<unsigned>::max();
unsigned ElemSizeArg = Num >> 32;
Optional<unsigned> NumElemsArg;
if (NumElems != AllocSizeNumElemsNotPresent)
NumElemsArg = NumElems;
return std::make_pair(ElemSizeArg, NumElemsArg);
}
Convert to storing the attribute's internals as enums, integers, and strings. The stuff we're handing are all enums (Attribute::AttrKind), integers and strings. Don't convert them to Constants, which is an unnecessary step here. The rest of the changes are mostly mechanical. llvm-svn: 174456
2013-02-06 06:37:24 +08:00
Attribute Attribute::get(LLVMContext &Context, Attribute::AttrKind Kind,
uint64_t Val) {
Begin the transition to using the AttributesImpl object for the Attributes ivar. Start using the AttributesImpl object to hold the value of the attributes. All queries go through the interfaces now. This has one unfortunate consequence. I needed to move the AttributesImpl.h file into include/llvm. But this is only temporary! Otherwise, the changes needed to support this would be too large. llvm-svn: 165433
2012-10-09 05:47:17 +08:00
LLVMContextImpl *pImpl = Context.pImpl;
FoldingSetNodeID ID;
Convert to storing the attribute's internals as enums, integers, and strings. The stuff we're handing are all enums (Attribute::AttrKind), integers and strings. Don't convert them to Constants, which is an unnecessary step here. The rest of the changes are mostly mechanical. llvm-svn: 174456
2013-02-06 06:37:24 +08:00
ID.AddInteger(Kind);
Revert accidentally committed r217107 "Don't treat 0 as a special value for int attributes." llvm-svn: 217110
2014-09-04 07:38:05 +08:00
if (Val) ID.AddInteger(Val);
Begin the transition to using the AttributesImpl object for the Attributes ivar. Start using the AttributesImpl object to hold the value of the attributes. All queries go through the interfaces now. This has one unfortunate consequence. I needed to move the AttributesImpl.h file into include/llvm. But this is only temporary! Otherwise, the changes needed to support this would be too large. llvm-svn: 165433
2012-10-09 05:47:17 +08:00
void *InsertPoint;
s/AttributesImpl/AttributeImpl/g This is going to apply to Attribute, not Attributes. llvm-svn: 170631
2012-12-20 09:36:59 +08:00
AttributeImpl *PA = pImpl->AttrsSet.FindNodeOrInsertPos(ID, InsertPoint);
Begin the transition to using the AttributesImpl object for the Attributes ivar. Start using the AttributesImpl object to hold the value of the attributes. All queries go through the interfaces now. This has one unfortunate consequence. I needed to move the AttributesImpl.h file into include/llvm. But this is only temporary! Otherwise, the changes needed to support this would be too large. llvm-svn: 165433
2012-10-09 05:47:17 +08:00
if (!PA) {
// If we didn't find any existing attributes of the same shape then create a
// new one and insert it.
Revert accidentally committed r217107 "Don't treat 0 as a special value for int attributes." llvm-svn: 217110
2014-09-04 07:38:05 +08:00
if (!Val)
[IR] Make Attributes and AttributeLists trivially destructible and BumpPtrAllocate them
2020-05-01 20:12:17 +08:00
PA = new (pImpl->Alloc) EnumAttributeImpl(Kind);
Revert accidentally committed r217107 "Don't treat 0 as a special value for int attributes." llvm-svn: 217110
2014-09-04 07:38:05 +08:00
else
[IR] Make Attributes and AttributeLists trivially destructible and BumpPtrAllocate them
2020-05-01 20:12:17 +08:00
PA = new (pImpl->Alloc) IntAttributeImpl(Kind, Val);
Begin the transition to using the AttributesImpl object for the Attributes ivar. Start using the AttributesImpl object to hold the value of the attributes. All queries go through the interfaces now. This has one unfortunate consequence. I needed to move the AttributesImpl.h file into include/llvm. But this is only temporary! Otherwise, the changes needed to support this would be too large. llvm-svn: 165433
2012-10-09 05:47:17 +08:00
pImpl->AttrsSet.InsertNode(PA, InsertPoint);
}
Add target-dependent versions of addAttribute/removeAttribute to AttrBuilder. llvm-svn: 174356
2013-02-05 16:09:32 +08:00
// Return the Attribute that we found or created.
Rename the 'Attributes' class to 'Attribute'. It's going to represent a single attribute in the future. llvm-svn: 170502
2012-12-19 15:18:57 +08:00
return Attribute(PA);
Begin the transition to using the AttributesImpl object for the Attributes ivar. Start using the AttributesImpl object to hold the value of the attributes. All queries go through the interfaces now. This has one unfortunate consequence. I needed to move the AttributesImpl.h file into include/llvm. But this is only temporary! Otherwise, the changes needed to support this would be too large. llvm-svn: 165433
2012-10-09 05:47:17 +08:00
}
Convert to storing the attribute's internals as enums, integers, and strings. The stuff we're handing are all enums (Attribute::AttrKind), integers and strings. Don't convert them to Constants, which is an unnecessary step here. The rest of the changes are mostly mechanical. llvm-svn: 174456
2013-02-06 06:37:24 +08:00
Attribute Attribute::get(LLVMContext &Context, StringRef Kind, StringRef Val) {
LLVMContextImpl *pImpl = Context.pImpl;
FoldingSetNodeID ID;
ID.AddString(Kind);
if (!Val.empty()) ID.AddString(Val);
void *InsertPoint;
AttributeImpl *PA = pImpl->AttrsSet.FindNodeOrInsertPos(ID, InsertPoint);
if (!PA) {
// If we didn't find any existing attributes of the same shape then create a
// new one and insert it.
[IR] Make Attributes and AttributeLists trivially destructible and BumpPtrAllocate them
2020-05-01 20:12:17 +08:00
void *Mem =
pImpl->Alloc.Allocate(StringAttributeImpl::totalSizeToAlloc(Kind, Val),
alignof(StringAttributeImpl));
PA = new (Mem) StringAttributeImpl(Kind, Val);
Convert to storing the attribute's internals as enums, integers, and strings. The stuff we're handing are all enums (Attribute::AttrKind), integers and strings. Don't convert them to Constants, which is an unnecessary step here. The rest of the changes are mostly mechanical. llvm-svn: 174456
2013-02-06 06:37:24 +08:00
pImpl->AttrsSet.InsertNode(PA, InsertPoint);
}
// Return the Attribute that we found or created.
return Attribute(PA);
Remove the AttrBuilder form of the Attribute::get creators. The AttrBuilder is for building a collection of attributes. The Attribute object holds only one attribute. So it's not really useful for the Attribute object to have a creator which takes an AttrBuilder. This has two fallouts: 1. The AttrBuilder no longer holds its internal attributes in a bit-mask form. 2. The attributes are now ordered alphabetically (hence why the tests have changed). llvm-svn: 174110
2013-02-01 07:16:25 +08:00
}
Reapply: IR: add optional type to 'byval' function parameters When we switch to opaque pointer types we will need some way to describe how many bytes a 'byval' parameter should occupy on the stack. This adds a (for now) optional extra type parameter. If present, the type must match the pointee type of the argument. The original commit did not remap byval types when linking modules, which broke LTO. This version fixes that. Note to front-end maintainers: if this causes test failures, it's probably because the "byval" attribute is printed after attributes without any parameter after this change. llvm-svn: 362128
2019-05-31 02:48:23 +08:00
Attribute Attribute::get(LLVMContext &Context, Attribute::AttrKind Kind,
Type *Ty) {
LLVMContextImpl *pImpl = Context.pImpl;
FoldingSetNodeID ID;
ID.AddInteger(Kind);
ID.AddPointer(Ty);
void *InsertPoint;
AttributeImpl *PA = pImpl->AttrsSet.FindNodeOrInsertPos(ID, InsertPoint);
if (!PA) {
// If we didn't find any existing attributes of the same shape then create a
// new one and insert it.
[IR] Make Attributes and AttributeLists trivially destructible and BumpPtrAllocate them
2020-05-01 20:12:17 +08:00
PA = new (pImpl->Alloc) TypeAttributeImpl(Kind, Ty);
Reapply: IR: add optional type to 'byval' function parameters When we switch to opaque pointer types we will need some way to describe how many bytes a 'byval' parameter should occupy on the stack. This adds a (for now) optional extra type parameter. If present, the type must match the pointee type of the argument. The original commit did not remap byval types when linking modules, which broke LTO. This version fixes that. Note to front-end maintainers: if this causes test failures, it's probably because the "byval" attribute is printed after attributes without any parameter after this change. llvm-svn: 362128
2019-05-31 02:48:23 +08:00
pImpl->AttrsSet.InsertNode(PA, InsertPoint);
}
// Return the Attribute that we found or created.
return Attribute(PA);
}
[Alignment] Migrate Attribute::getWith(Stack)Alignment Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet, jdoerfert Reviewed By: courbet Subscribers: arsenm, jvesely, nhaehnle, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D68792 llvm-svn: 374884
2019-10-15 20:56:24 +08:00
Attribute Attribute::getWithAlignment(LLVMContext &Context, Align A) {
[IR] Attribute/AttrBuilder: use Value::MaximumAlignment magic constant Summary: I initially encountered those assertions when trying to create this IR `alignment` attribute from clang's `__attribute__((assume_aligned(imm)))`, because until D72994 there is no sanity checking for the value of `imm`. But even then, we have `llvm::Value::MaximumAlignment` constant (which is `536870912`), which is enforced for clang attributes, and then there are some other magical constant (`0x40000000` i.e. `1073741824` i.e. `2 * 536870912`) in `Attribute::getWithAlignment()`/`AttrBuilder::addAlignmentAttr()`. I strongly suspect that `0x40000000` is incorrect, and that also should be `llvm::Value::MaximumAlignment`. Reviewers: erichkeane, hfinkel, jdoerfert, gchatelet, courbet Reviewed By: erichkeane Subscribers: hiraditya, cfe-commits, llvm-commits Tags: #llvm, #clang Differential Revision: https://reviews.llvm.org/D72998
2020-01-24 03:50:06 +08:00
assert(A <= llvm::Value::MaximumAlignment && "Alignment too large.");
[Alignment] Migrate Attribute::getWith(Stack)Alignment Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet, jdoerfert Reviewed By: courbet Subscribers: arsenm, jvesely, nhaehnle, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D68792 llvm-svn: 374884
2019-10-15 20:56:24 +08:00
return get(Context, Alignment, A.value());
Add special 'get' methods to create an Attribute with an alignment. Also do some random cleanup. No functionality change. llvm-svn: 173635
2013-01-28 06:43:04 +08:00
}
[Alignment] Migrate Attribute::getWith(Stack)Alignment Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet, jdoerfert Reviewed By: courbet Subscribers: arsenm, jvesely, nhaehnle, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D68792 llvm-svn: 374884
2019-10-15 20:56:24 +08:00
Attribute Attribute::getWithStackAlignment(LLVMContext &Context, Align A) {
assert(A <= 0x100 && "Alignment too large.");
return get(Context, StackAlignment, A.value());
Add special 'get' methods to create an Attribute with an alignment. Also do some random cleanup. No functionality change. llvm-svn: 173635
2013-01-28 06:43:04 +08:00
}
Add a dereferenceable attribute This attribute indicates that the parameter or return pointer is dereferenceable. Practically speaking, loads from such a pointer within the associated byte range are safe to speculatively execute. Such pointer parameters are common in source languages (C++ references, for example). llvm-svn: 213385
2014-07-18 23:51:28 +08:00
Attribute Attribute::getWithDereferenceableBytes(LLVMContext &Context,
uint64_t Bytes) {
assert(Bytes && "Bytes must be non-zero.");
return get(Context, Dereferenceable, Bytes);
}
[IR] Introduce a dereferenceable_or_null(N) attribute. Summary: If a pointer is marked as dereferenceable_or_null(N), LLVM assumes it is either `null` or `dereferenceable(N)` or both. This change only introduces the attribute and adds a token test case for the `llvm-as` / `llvm-dis`. It does not hook up other parts of the optimizer to actually exploit the attribute -- those changes will come later. For pointers in address space 0, `dereferenceable(N)` is now exactly equivalent to `dereferenceable_or_null(N)` && `nonnull`. For other address spaces, `dereferenceable(N)` is potentially weaker than `dereferenceable_or_null(N)` && `nonnull` (since we could have a null `dereferenceable(N)` pointer). The motivating case for this change is Java (and other managed languages), where pointers are either `null` or dereferenceable up to some usually known-at-compile-time constant offset. Reviewers: rafael, hfinkel Reviewed By: hfinkel Subscribers: nicholas, llvm-commits Differential Revision: http://reviews.llvm.org/D8650 llvm-svn: 235132
2015-04-17 04:29:50 +08:00
Attribute Attribute::getWithDereferenceableOrNullBytes(LLVMContext &Context,
uint64_t Bytes) {
assert(Bytes && "Bytes must be non-zero.");
return get(Context, DereferenceableOrNull, Bytes);
}
Reapply: IR: add optional type to 'byval' function parameters When we switch to opaque pointer types we will need some way to describe how many bytes a 'byval' parameter should occupy on the stack. This adds a (for now) optional extra type parameter. If present, the type must match the pointee type of the argument. The original commit did not remap byval types when linking modules, which broke LTO. This version fixes that. Note to front-end maintainers: if this causes test failures, it's probably because the "byval" attribute is printed after attributes without any parameter after this change. llvm-svn: 362128
2019-05-31 02:48:23 +08:00
Attribute Attribute::getWithByValType(LLVMContext &Context, Type *Ty) {
return get(Context, ByVal, Ty);
}
Reapply "OpaquePtr: Add type to sret attribute" This reverts commit eb9f7c28e5fe6d75fed3587023e17f2997c8024b. Previously this was incorrectly handling linking of the contained type, so this merges the fixes from D88973.
2020-09-29 21:33:55 +08:00
Attribute Attribute::getWithStructRetType(LLVMContext &Context, Type *Ty) {
return get(Context, StructRet, Ty);
}
IR: Define byref parameter attribute This allows tracking the in-memory type of a pointer argument to a function for ABI purposes. This is essentially a stripped down version of byval to remove some of the stack-copy implications in its definition. This includes the base IR changes, and some tests for places where it should be treated similarly to byval. Codegen support will be in a future patch. My original attempt at solving some of these problems was to repurpose byval with a different address space from the stack. However, it is technically permitted for the callee to introduce a write to the argument, although nothing does this in reality. There is also talk of removing and replacing the byval attribute, so a new attribute would need to take its place anyway. This is intended avoid some optimization issues with the current handling of aggregate arguments, as well as fixes inflexibilty in how frontends can specify the kernel ABI. The most honest representation of the amdgpu_kernel convention is to expose all kernel arguments as loads from constant memory. Today, these are raw, SSA Argument values and codegen is responsible for turning these into loads. Background: There currently isn't a satisfactory way to represent how arguments for the amdgpu_kernel calling convention are passed. In reality, arguments are passed in a single, flat, constant memory buffer implicitly passed to the function. It is also illegal to call this function in the IR, and this is only ever invoked by a driver of some kind. It does not make sense to have a stack passed parameter in this context as is implied by byval. It is never valid to write to the kernel arguments, as this would corrupt the inputs seen by other dispatches of the kernel. These argumets are also not in the same address space as the stack, so a copy is needed to an alloca. From a source C-like language, the kernel parameters are invisible. Semantically, a copy is always required from the constant argument memory to a mutable variable. The current clang calling convention lowering emits raw values, including aggregates into the function argument list, since using byval would not make sense. This has some unfortunate consequences for the optimizer. In the aggregate case, we end up with an aggregate store to alloca, which both SROA and instcombine turn into a store of each aggregate field. The optimizer never pieces this back together to see that this is really just a copy from constant memory, so we end up stuck with expensive stack usage. This also means the backend dictates the alignment of arguments, and arbitrarily picks the LLVM IR ABI type alignment. By allowing an explicit alignment, frontends can make better decisions. For example, there's real no advantage to an aligment higher than 4, so a frontend could choose to compact the argument layout. Similarly, there is a high penalty to using an alignment lower than 4, so a frontend could opt into more padding for small arguments. Another design consideration is when it is appropriate to expose the fact that these arguments are all really passed in adjacent memory. Currently we have a late IR optimization pass in codegen to rewrite the kernel argument values into explicit loads to enable vectorization. In most programs, unrelated argument loads can be merged together. However, exposing this property directly from the frontend has some disadvantages. We still need a way to track the original argument sizes and alignments to report to the driver. I find using some side-channel, metadata mechanism to track this unappealing. If the kernel arguments were exposed as a single buffer to begin with, alias analysis would be unaware that the padding bits betewen arguments are meaningless. Another family of problems is there are still some gaps in replacing all of the available parameter attributes with metadata equivalents once lowered to loads. The immediate plan is to start using this new attribute to handle all aggregate argumets for kernels. Long term, it makes sense to migrate all kernel arguments, including scalars, to be passed indirectly in the same manner. Additional context is in D79744.
2020-06-06 04:58:47 +08:00
Attribute Attribute::getWithByRefType(LLVMContext &Context, Type *Ty) {
return get(Context, ByRef, Ty);
}
Add IR constructs for preallocated (inalloca replacement) Add llvm.call.preallocated.{setup,arg} instrinsics. Add "preallocated" operand bundle which takes a token produced by llvm.call.preallocated.setup. Add "preallocated" parameter attribute, which is like byval but without the copy. Verifier changes for these IR constructs. See https://github.com/rnk/llvm-project/blob/call-setup-docs/llvm/docs/CallSetup.md Subscribers: hiraditya, jdoerfert, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D74651
2020-02-15 06:16:53 +08:00
Attribute Attribute::getWithPreallocatedType(LLVMContext &Context, Type *Ty) {
return get(Context, Preallocated, Ty);
}
Add the allocsize attribute to LLVM. `allocsize` is a function attribute that allows users to request that LLVM treat arbitrary functions as allocation functions. This patch makes LLVM accept the `allocsize` attribute, and makes `@llvm.objectsize` recognize said attribute. The review for this was split into two patches for ease of reviewing: D18974 and D14933. As promised on the revisions, I'm landing both patches as a single commit. Differential Revision: http://reviews.llvm.org/D14933 llvm-svn: 266032
2016-04-12 09:05:35 +08:00
Attribute
Attribute::getWithAllocSizeArgs(LLVMContext &Context, unsigned ElemSizeArg,
const Optional<unsigned> &NumElemsArg) {
assert(!(ElemSizeArg == 0 && NumElemsArg && *NumElemsArg == 0) &&
"Invalid allocsize arguments -- given allocsize(0, 0)");
return get(Context, AllocSize, packAllocSizeArgs(ElemSizeArg, NumElemsArg));
}
Build assume from call Fix attempt this is part of the implementation of http://lists.llvm.org/pipermail/llvm-dev/2019-December/137632.html this patch gives the basis of building an assume to preserve all information from an instruction and add support for building an assume that preserve the information from a call.
2020-02-02 21:46:59 +08:00
Attribute::AttrKind Attribute::getAttrKindFromName(StringRef AttrName) {
return StringSwitch<Attribute::AttrKind>(AttrName)
#define GET_ATTR_NAMES
#define ATTRIBUTE_ENUM(ENUM_NAME, DISPLAY_NAME) \
.Case(#DISPLAY_NAME, Attribute::ENUM_NAME)
#include "llvm/IR/Attributes.inc"
.Default(Attribute::None);
}
StringRef Attribute::getNameFromAttrKind(Attribute::AttrKind AttrKind) {
switch (AttrKind) {
#define GET_ATTR_NAMES
#define ATTRIBUTE_ENUM(ENUM_NAME, DISPLAY_NAME) \
case Attribute::ENUM_NAME: \
return #DISPLAY_NAME;
#include "llvm/IR/Attributes.inc"
case Attribute::None:
return "none";
default:
llvm_unreachable("invalid Kind");
}
}
[NFC] Factor out function to detect if an attribute has an argument.
2020-02-02 21:47:00 +08:00
bool Attribute::doesAttrKindHaveArgument(Attribute::AttrKind AttrKind) {
return AttrKind == Attribute::Alignment ||
AttrKind == Attribute::StackAlignment ||
AttrKind == Attribute::Dereferenceable ||
AttrKind == Attribute::AllocSize ||
AttrKind == Attribute::DereferenceableOrNull;
}
[AssumeBundles] Enforce constraints on the operand bundle of llvm.assume Summary: Add verification that operand bundles on an llvm.assume are well formed to the verify pass. Reviewers: jdoerfert Reviewed By: jdoerfert Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D75269
2020-03-12 06:21:44 +08:00
bool Attribute::isExistingAttribute(StringRef Name) {
return StringSwitch<bool>(Name)
#define GET_ATTR_NAMES
#define ATTRIBUTE_ALL(ENUM_NAME, DISPLAY_NAME) .Case(#DISPLAY_NAME, true)
#include "llvm/IR/Attributes.inc"
.Default(false);
}
S'more small non-functional changes in comments and #includes. llvm-svn: 173738
2013-01-29 08:48:16 +08:00
//===----------------------------------------------------------------------===//
// Attribute Accessor Methods
//===----------------------------------------------------------------------===//
Convert to storing the attribute's internals as enums, integers, and strings. The stuff we're handing are all enums (Attribute::AttrKind), integers and strings. Don't convert them to Constants, which is an unnecessary step here. The rest of the changes are mostly mechanical. llvm-svn: 174456
2013-02-06 06:37:24 +08:00
bool Attribute::isEnumAttribute() const {
return pImpl && pImpl->isEnumAttribute();
Move methods out-of-line. The internal representation of the Attributes class will be opaque. All of the query methods will need to query the opaque class. Therefore, these methods need to be out-of-line. No functionality change intended. llvm-svn: 165305
2012-10-05 14:44:41 +08:00
}
Rename AlignAttribute to IntAttribute Currently the only kind of integer IR attributes that we have are alignment attributes, and so the attribute kind that takes an integer parameter is called AlignAttr, but that will change (we'll soon be adding a dereferenceable attribute that also takes an integer value). Accordingly, rename AlignAttribute to IntAttribute (class names, enums, etc.). No functionality change intended. llvm-svn: 213352
2014-07-18 14:51:55 +08:00
bool Attribute::isIntAttribute() const {
return pImpl && pImpl->isIntAttribute();
Add a couple of accessor methods to get the kind and values of an attribute. llvm-svn: 173828
2013-01-30 04:45:34 +08:00
}
Convert to storing the attribute's internals as enums, integers, and strings. The stuff we're handing are all enums (Attribute::AttrKind), integers and strings. Don't convert them to Constants, which is an unnecessary step here. The rest of the changes are mostly mechanical. llvm-svn: 174456
2013-02-06 06:37:24 +08:00
bool Attribute::isStringAttribute() const {
return pImpl && pImpl->isStringAttribute();
}
Reapply: IR: add optional type to 'byval' function parameters When we switch to opaque pointer types we will need some way to describe how many bytes a 'byval' parameter should occupy on the stack. This adds a (for now) optional extra type parameter. If present, the type must match the pointee type of the argument. The original commit did not remap byval types when linking modules, which broke LTO. This version fixes that. Note to front-end maintainers: if this causes test failures, it's probably because the "byval" attribute is printed after attributes without any parameter after this change. llvm-svn: 362128
2019-05-31 02:48:23 +08:00
bool Attribute::isTypeAttribute() const {
return pImpl && pImpl->isTypeAttribute();
}
Convert to storing the attribute's internals as enums, integers, and strings. The stuff we're handing are all enums (Attribute::AttrKind), integers and strings. Don't convert them to Constants, which is an unnecessary step here. The rest of the changes are mostly mechanical. llvm-svn: 174456
2013-02-06 06:37:24 +08:00
Attribute::AttrKind Attribute::getKindAsEnum() const {
Replace the "NoFramePointerElimNonLeaf" target option with a function attribute. There's no need to specify a flag to omit frame pointer elimination on non-leaf nodes...(Honestly, I can't parse that option out.) Use the function attribute stuff instead. llvm-svn: 187093
2013-07-25 08:34:29 +08:00
if (!pImpl) return None;
Reapply: IR: add optional type to 'byval' function parameters When we switch to opaque pointer types we will need some way to describe how many bytes a 'byval' parameter should occupy on the stack. This adds a (for now) optional extra type parameter. If present, the type must match the pointee type of the argument. The original commit did not remap byval types when linking modules, which broke LTO. This version fixes that. Note to front-end maintainers: if this causes test failures, it's probably because the "byval" attribute is printed after attributes without any parameter after this change. llvm-svn: 362128
2019-05-31 02:48:23 +08:00
assert((isEnumAttribute() || isIntAttribute() || isTypeAttribute()) &&
Convert to storing the attribute's internals as enums, integers, and strings. The stuff we're handing are all enums (Attribute::AttrKind), integers and strings. Don't convert them to Constants, which is an unnecessary step here. The rest of the changes are mostly mechanical. llvm-svn: 174456
2013-02-06 06:37:24 +08:00
"Invalid attribute type to get the kind as an enum!");
Minor cleanup of Attribute code. NFC. llvm-svn: 255751
2015-12-16 13:21:02 +08:00
return pImpl->getKindAsEnum();
Convert to storing the attribute's internals as enums, integers, and strings. The stuff we're handing are all enums (Attribute::AttrKind), integers and strings. Don't convert them to Constants, which is an unnecessary step here. The rest of the changes are mostly mechanical. llvm-svn: 174456
2013-02-06 06:37:24 +08:00
}
uint64_t Attribute::getValueAsInt() const {
Replace the "NoFramePointerElimNonLeaf" target option with a function attribute. There's no need to specify a flag to omit frame pointer elimination on non-leaf nodes...(Honestly, I can't parse that option out.) Use the function attribute stuff instead. llvm-svn: 187093
2013-07-25 08:34:29 +08:00
if (!pImpl) return 0;
Rename AlignAttribute to IntAttribute Currently the only kind of integer IR attributes that we have are alignment attributes, and so the attribute kind that takes an integer parameter is called AlignAttr, but that will change (we'll soon be adding a dereferenceable attribute that also takes an integer value). Accordingly, rename AlignAttribute to IntAttribute (class names, enums, etc.). No functionality change intended. llvm-svn: 213352
2014-07-18 14:51:55 +08:00
assert(isIntAttribute() &&
"Expected the attribute to be an integer attribute!");
Minor cleanup of Attribute code. NFC. llvm-svn: 255751
2015-12-16 13:21:02 +08:00
return pImpl->getValueAsInt();
Convert to storing the attribute's internals as enums, integers, and strings. The stuff we're handing are all enums (Attribute::AttrKind), integers and strings. Don't convert them to Constants, which is an unnecessary step here. The rest of the changes are mostly mechanical. llvm-svn: 174456
2013-02-06 06:37:24 +08:00
}
StringRef Attribute::getKindAsString() const {
[IR] Fix some Clang-tidy modernize-use-auto warnings; other minor fixes (NFC). llvm-svn: 328850
2018-03-30 08:47:31 +08:00
if (!pImpl) return {};
Convert to storing the attribute's internals as enums, integers, and strings. The stuff we're handing are all enums (Attribute::AttrKind), integers and strings. Don't convert them to Constants, which is an unnecessary step here. The rest of the changes are mostly mechanical. llvm-svn: 174456
2013-02-06 06:37:24 +08:00
assert(isStringAttribute() &&
"Invalid attribute type to get the kind as a string!");
Minor cleanup of Attribute code. NFC. llvm-svn: 255751
2015-12-16 13:21:02 +08:00
return pImpl->getKindAsString();
Convert to storing the attribute's internals as enums, integers, and strings. The stuff we're handing are all enums (Attribute::AttrKind), integers and strings. Don't convert them to Constants, which is an unnecessary step here. The rest of the changes are mostly mechanical. llvm-svn: 174456
2013-02-06 06:37:24 +08:00
}
StringRef Attribute::getValueAsString() const {
[IR] Fix some Clang-tidy modernize-use-auto warnings; other minor fixes (NFC). llvm-svn: 328850
2018-03-30 08:47:31 +08:00
if (!pImpl) return {};
Convert to storing the attribute's internals as enums, integers, and strings. The stuff we're handing are all enums (Attribute::AttrKind), integers and strings. Don't convert them to Constants, which is an unnecessary step here. The rest of the changes are mostly mechanical. llvm-svn: 174456
2013-02-06 06:37:24 +08:00
assert(isStringAttribute() &&
"Invalid attribute type to get the value as a string!");
Minor cleanup of Attribute code. NFC. llvm-svn: 255751
2015-12-16 13:21:02 +08:00
return pImpl->getValueAsString();
Convert to storing the attribute's internals as enums, integers, and strings. The stuff we're handing are all enums (Attribute::AttrKind), integers and strings. Don't convert them to Constants, which is an unnecessary step here. The rest of the changes are mostly mechanical. llvm-svn: 174456
2013-02-06 06:37:24 +08:00
}
Reapply: IR: add optional type to 'byval' function parameters When we switch to opaque pointer types we will need some way to describe how many bytes a 'byval' parameter should occupy on the stack. This adds a (for now) optional extra type parameter. If present, the type must match the pointee type of the argument. The original commit did not remap byval types when linking modules, which broke LTO. This version fixes that. Note to front-end maintainers: if this causes test failures, it's probably because the "byval" attribute is printed after attributes without any parameter after this change. llvm-svn: 362128
2019-05-31 02:48:23 +08:00
Type *Attribute::getValueAsType() const {
if (!pImpl) return {};
assert(isTypeAttribute() &&
"Invalid attribute type to get the value as a type!");
return pImpl->getValueAsType();
}
Add the target-dependent (string) attributes from the AttrBuilder to the AttributeSet. llvm-svn: 174467
2013-02-06 07:48:36 +08:00
bool Attribute::hasAttribute(AttrKind Kind) const {
return (pImpl && pImpl->hasAttribute(Kind)) || (!pImpl && Kind == None);
}
bool Attribute::hasAttribute(StringRef Kind) const {
if (!isStringAttribute()) return false;
return pImpl && pImpl->hasAttribute(Kind);
Add a couple of accessor methods to get the kind and values of an attribute. llvm-svn: 173828
2013-01-30 04:45:34 +08:00
}
[Alignment][NFC] Attributes use Align/MaybeAlign Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Subscribers: jholewinski, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69278 llvm-svn: 375495
2019-10-22 17:51:06 +08:00
MaybeAlign Attribute::getAlignment() const {
Remove some dead code, improve some asserts, and other assorted changes. No functionality change. llvm-svn: 174132
2013-02-01 09:04:27 +08:00
assert(hasAttribute(Attribute::Alignment) &&
"Trying to get alignment from non-alignment attribute!");
[Alignment][NFC] Attributes use Align/MaybeAlign Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Subscribers: jholewinski, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69278 llvm-svn: 375495
2019-10-22 17:51:06 +08:00
return MaybeAlign(pImpl->getValueAsInt());
Move methods out-of-line. The internal representation of the Attributes class will be opaque. All of the query methods will need to query the opaque class. Therefore, these methods need to be out-of-line. No functionality change intended. llvm-svn: 165305
2012-10-05 14:44:41 +08:00
}
[Alignment][NFC] Attributes use Align/MaybeAlign Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Subscribers: jholewinski, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69278 llvm-svn: 375495
2019-10-22 17:51:06 +08:00
MaybeAlign Attribute::getStackAlignment() const {
Remove some dead code, improve some asserts, and other assorted changes. No functionality change. llvm-svn: 174132
2013-02-01 09:04:27 +08:00
assert(hasAttribute(Attribute::StackAlignment) &&
"Trying to get alignment from non-alignment attribute!");
[Alignment][NFC] Attributes use Align/MaybeAlign Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Subscribers: jholewinski, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69278 llvm-svn: 375495
2019-10-22 17:51:06 +08:00
return MaybeAlign(pImpl->getValueAsInt());
Move methods out-of-line. The internal representation of the Attributes class will be opaque. All of the query methods will need to query the opaque class. Therefore, these methods need to be out-of-line. No functionality change intended. llvm-svn: 165305
2012-10-05 14:44:41 +08:00
}
Add a dereferenceable attribute This attribute indicates that the parameter or return pointer is dereferenceable. Practically speaking, loads from such a pointer within the associated byte range are safe to speculatively execute. Such pointer parameters are common in source languages (C++ references, for example). llvm-svn: 213385
2014-07-18 23:51:28 +08:00
uint64_t Attribute::getDereferenceableBytes() const {
assert(hasAttribute(Attribute::Dereferenceable) &&
"Trying to get dereferenceable bytes from "
"non-dereferenceable attribute!");
return pImpl->getValueAsInt();
}
[IR] Introduce a dereferenceable_or_null(N) attribute. Summary: If a pointer is marked as dereferenceable_or_null(N), LLVM assumes it is either `null` or `dereferenceable(N)` or both. This change only introduces the attribute and adds a token test case for the `llvm-as` / `llvm-dis`. It does not hook up other parts of the optimizer to actually exploit the attribute -- those changes will come later. For pointers in address space 0, `dereferenceable(N)` is now exactly equivalent to `dereferenceable_or_null(N)` && `nonnull`. For other address spaces, `dereferenceable(N)` is potentially weaker than `dereferenceable_or_null(N)` && `nonnull` (since we could have a null `dereferenceable(N)` pointer). The motivating case for this change is Java (and other managed languages), where pointers are either `null` or dereferenceable up to some usually known-at-compile-time constant offset. Reviewers: rafael, hfinkel Reviewed By: hfinkel Subscribers: nicholas, llvm-commits Differential Revision: http://reviews.llvm.org/D8650 llvm-svn: 235132
2015-04-17 04:29:50 +08:00
uint64_t Attribute::getDereferenceableOrNullBytes() const {
assert(hasAttribute(Attribute::DereferenceableOrNull) &&
"Trying to get dereferenceable bytes from "
"non-dereferenceable attribute!");
return pImpl->getValueAsInt();
}
Add the allocsize attribute to LLVM. `allocsize` is a function attribute that allows users to request that LLVM treat arbitrary functions as allocation functions. This patch makes LLVM accept the `allocsize` attribute, and makes `@llvm.objectsize` recognize said attribute. The review for this was split into two patches for ease of reviewing: D18974 and D14933. As promised on the revisions, I'm landing both patches as a single commit. Differential Revision: http://reviews.llvm.org/D14933 llvm-svn: 266032
2016-04-12 09:05:35 +08:00
std::pair<unsigned, Optional<unsigned>> Attribute::getAllocSizeArgs() const {
assert(hasAttribute(Attribute::AllocSize) &&
"Trying to get allocsize args from non-allocsize attribute");
return unpackAllocSizeArgs(pImpl->getValueAsInt());
}
Add support for printing out the attribute groups. This emits the attribute groups that are used by the functions. (It currently doesn't print out return type or parameter attributes within attribute groups.) Note: The functions still retrieve their attributes from the "old" bitcode format (using the deprecated 'Raw()' method). This means that string attributes within an attribute group will not show up during a disassembly. This will be addressed in a future commit. llvm-svn: 174867
2013-02-11 16:43:33 +08:00
std::string Attribute::getAsString(bool InAttrGrp) const {
[IR] Fix some Clang-tidy modernize-use-auto warnings; other minor fixes (NFC). llvm-svn: 328850
2018-03-30 08:47:31 +08:00
if (!pImpl) return {};
Add support for emitting a string attribute. Attributes that are strings are typically target-dependent attributes. They are of this form in the IR: "attr" "attr" = "val" llvm-svn: 174090
2013-02-01 04:59:05 +08:00
Unify clang/llvm attributes for asan/tsan/msan (LLVM part) These are two related changes (one in llvm, one in clang). LLVM: - rename address_safety => sanitize_address (the enum value is the same, so we preserve binary compatibility with old bitcode) - rename thread_safety => sanitize_thread - rename no_uninitialized_checks -> sanitize_memory CLANG: - add __attribute__((no_sanitize_address)) as a synonym for __attribute__((no_address_safety_analysis)) - add __attribute__((no_sanitize_thread)) - add __attribute__((no_sanitize_memory)) for S in address thread memory If -fsanitize=S is present and __attribute__((no_sanitize_S)) is not set llvm attribute sanitize_S llvm-svn: 176075
2013-02-26 14:58:09 +08:00
if (hasAttribute(Attribute::SanitizeAddress))
return "sanitize_address";
Hardware-assisted AddressSanitizer (llvm part). Summary: This is LLVM instrumentation for the new HWASan tool. It is basically a stripped down copy of ASan at this point, w/o stack or global support. Instrumenation adds a global constructor + runtime callbacks for every load and store. HWASan comes with its own IR attribute. A brief design document can be found in clang/docs/HardwareAssistedAddressSanitizerDesign.rst (submitted earlier). Reviewers: kcc, pcc, alekseyshl Subscribers: srhines, mehdi_amini, mgorny, javed.absar, eraman, llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D40932 llvm-svn: 320217
2017-12-09 08:21:41 +08:00
if (hasAttribute(Attribute::SanitizeHWAddress))
return "sanitize_hwaddress";
ARM MTE stack sanitizer. Add "memtag" sanitizer that detects and mitigates stack memory issues using armv8.5 Memory Tagging Extension. It is similar in principle to HWASan, which is a software implementation of the same idea, but there are enough differencies to warrant a new sanitizer type IMHO. It is also expected to have very different performance properties. The new sanitizer does not have a runtime library (it may grow one later, along with a "debugging" mode). Similar to SafeStack and StackProtector, the instrumentation pass (in a follow up change) will be inserted in all cases, but will only affect functions marked with the new sanitize_memtag attribute. Reviewers: pcc, hctim, vitalybuka, ostannard Subscribers: srhines, mehdi_amini, javed.absar, kristof.beyls, hiraditya, cryptoad, steven_wu, dexonsmith, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D64169 llvm-svn: 366123
2019-07-16 04:02:23 +08:00
if (hasAttribute(Attribute::SanitizeMemTag))
return "sanitize_memtag";
Add support for emitting a string attribute. Attributes that are strings are typically target-dependent attributes. They are of this form in the IR: "attr" "attr" = "val" llvm-svn: 174090
2013-02-01 04:59:05 +08:00
if (hasAttribute(Attribute::AlwaysInline))
return "alwaysinline";
Add argmemonly attribute. This change adds new attribute called "argmemonly". Function marked with this attribute can only access memory through it's argument pointers. This attribute directly corresponds to the "OnlyAccessesArgumentPointees" ModRef behaviour in alias analysis. Differential Revision: http://reviews.llvm.org/D10398 llvm-svn: 241979
2015-07-11 18:30:36 +08:00
if (hasAttribute(Attribute::ArgMemOnly))
return "argmemonly";
Added support for the Builtin attribute. The Builtin attribute is an attribute that can be placed on function call site that signal that even though a function is declared as being a builtin, rdar://problem/13727199 llvm-svn: 185049
2013-06-27 08:25:01 +08:00
if (hasAttribute(Attribute::Builtin))
return "builtin";
Add initial support for the convergent attribute. llvm-svn: 238264
2015-05-27 07:48:40 +08:00
if (hasAttribute(Attribute::Convergent))
return "convergent";
Swift Calling Convention: add swifterror attribute. A ``swifterror`` attribute can be applied to a function parameter or an AllocaInst. This commit does not include any target-specific change. The target-specific optimization will come as a follow-up patch. Differential Revision: http://reviews.llvm.org/D18092 llvm-svn: 265189
2016-04-02 05:41:15 +08:00
if (hasAttribute(Attribute::SwiftError))
return "swifterror";
Swift Calling Convention: add swiftself attribute. Differential Revision: http://reviews.llvm.org/D17866 llvm-svn: 264754
2016-03-30 01:37:21 +08:00
if (hasAttribute(Attribute::SwiftSelf))
return "swiftself";
Add InaccessibleMemOnly and inaccessibleMemOrArgMemOnly attributes Summary: This patch introduces two new function attributes InaccessibleMemOnly: This attribute indicates that the function may only access memory that is not accessible by the program/IR being compiled. This is a weaker form of ReadNone. inaccessibleMemOrArgMemOnly: This attribute indicates that the function may only access memory that is either not accessible by the program/IR being compiled, or is pointed to by its pointer arguments. This is a weaker form of ArgMemOnly Test cases have been updated. This revision uses this (https://github.com/llvm-mirror/llvm/commit/d001932f3a8aa1ebd1555162fdce365f011bc292) as reference. Reviewers: jmolloy, hfinkel Subscribers: reames, joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D15499 llvm-svn: 255778
2015-12-17 00:16:19 +08:00
if (hasAttribute(Attribute::InaccessibleMemOnly))
return "inaccessiblememonly";
if (hasAttribute(Attribute::InaccessibleMemOrArgMemOnly))
return "inaccessiblemem_or_argmemonly";
Begin adding docs and IR-level support for the inalloca attribute The inalloca attribute is designed to support passing C++ objects by value in the Microsoft C++ ABI. It behaves the same as byval, except that it always implies that the argument is in memory and that the bytes are never copied. This attribute allows the caller to take the address of an outgoing argument's memory and execute arbitrary code to store into it. This patch adds basic IR support, docs, and verification. It does not attempt to implement any lowering or fix any possibly broken transforms. When this patch lands, a complete description of this feature should appear at http://llvm.org/docs/InAlloca.html . Differential Revision: http://llvm-reviews.chandlerc.com/D2173 llvm-svn: 197645
2013-12-19 10:14:12 +08:00
if (hasAttribute(Attribute::InAlloca))
return "inalloca";
Add support for emitting a string attribute. Attributes that are strings are typically target-dependent attributes. They are of this form in the IR: "attr" "attr" = "val" llvm-svn: 174090
2013-02-01 04:59:05 +08:00
if (hasAttribute(Attribute::InlineHint))
return "inlinehint";
Rename the 'Attributes' class to 'Attribute'. It's going to represent a single attribute in the future. llvm-svn: 170502
2012-12-19 15:18:57 +08:00
if (hasAttribute(Attribute::InReg))
Convert getAttributes() to return an AttributeSetNode. The AttributeSetNode contains all of the attributes. This removes one (hopefully last) use of the Attribute class as a container of multiple attributes. llvm-svn: 173761
2013-01-29 11:20:31 +08:00
return "inreg";
Add a new attribute called 'jumptable' that creates jump-instruction tables for functions marked with this attribute. It includes a pass that rewrites all indirect calls to jumptable functions to pass through these tables. This also adds backend support for generating the jump-instruction tables on ARM and X86. Note that since the jumptable attribute creates a second function pointer for a function, any function marked with jumptable must also be marked with unnamed_addr. llvm-svn: 210280
2014-06-06 03:29:43 +08:00
if (hasAttribute(Attribute::JumpTable))
return "jumptable";
Add support for emitting a string attribute. Attributes that are strings are typically target-dependent attributes. They are of this form in the IR: "attr" "attr" = "val" llvm-svn: 174090
2013-02-01 04:59:05 +08:00
if (hasAttribute(Attribute::MinSize))
return "minsize";
if (hasAttribute(Attribute::Naked))
return "naked";
if (hasAttribute(Attribute::Nest))
return "nest";
Rename the 'Attributes' class to 'Attribute'. It's going to represent a single attribute in the future. llvm-svn: 170502
2012-12-19 15:18:57 +08:00
if (hasAttribute(Attribute::NoAlias))
Convert getAttributes() to return an AttributeSetNode. The AttributeSetNode contains all of the attributes. This removes one (hopefully last) use of the Attribute class as a container of multiple attributes. llvm-svn: 173761
2013-01-29 11:20:31 +08:00
return "noalias";
Implement the NoBuiltin attribute. The 'nobuiltin' attribute is applied to call sites to indicate that LLVM should not treat the callee function as a built-in function. I.e., it shouldn't try to replace that function with different code. llvm-svn: 175835
2013-02-22 08:12:35 +08:00
if (hasAttribute(Attribute::NoBuiltin))
return "nobuiltin";
[clang][IR] Add support for leaf attribute This patch adds support for leaf attribute as an optimization hint in Clang/LLVM. Differential Revision: https://reviews.llvm.org/D90275
2020-12-15 05:56:11 +08:00
if (hasAttribute(Attribute::NoCallback))
return "nocallback";
Rename the 'Attributes' class to 'Attribute'. It's going to represent a single attribute in the future. llvm-svn: 170502
2012-12-19 15:18:57 +08:00
if (hasAttribute(Attribute::NoCapture))
Convert getAttributes() to return an AttributeSetNode. The AttributeSetNode contains all of the attributes. This removes one (hopefully last) use of the Attribute class as a container of multiple attributes. llvm-svn: 173761
2013-01-29 11:20:31 +08:00
return "nocapture";
Add support for emitting a string attribute. Attributes that are strings are typically target-dependent attributes. They are of this form in the IR: "attr" "attr" = "val" llvm-svn: 174090
2013-02-01 04:59:05 +08:00
if (hasAttribute(Attribute::NoDuplicate))
return "noduplicate";
Add, and infer, a nofree function attribute This patch adds a function attribute, nofree, to indicate that a function does not, directly or indirectly, call a memory-deallocation function (e.g., free, C++'s operator delete). Reviewers: jdoerfert Differential Revision: https://reviews.llvm.org/D49165 llvm-svn: 365336
2019-07-08 23:57:56 +08:00
if (hasAttribute(Attribute::NoFree))
return "nofree";
Add support for emitting a string attribute. Attributes that are strings are typically target-dependent attributes. They are of this form in the IR: "attr" "attr" = "val" llvm-svn: 174090
2013-02-01 04:59:05 +08:00
if (hasAttribute(Attribute::NoImplicitFloat))
return "noimplicitfloat";
if (hasAttribute(Attribute::NoInline))
return "noinline";
if (hasAttribute(Attribute::NonLazyBind))
return "nonlazybind";
Add nomerge function attribute to supress tail merge optimization in simplifyCFG We want to add a way to avoid merging identical calls so as to keep the separate debug-information for those calls. There is also an asan usecase where having this attribute would be beneficial to avoid alternative work-arounds. Here is the link to the feature request: https://bugs.llvm.org/show_bug.cgi?id=42783. `nomerge` is different from `noline`. `noinline` prevents function from inlining at callsites, but `nomerge` prevents multiple identical calls from being merged into one. This patch adds `nomerge` to disable the optimization in IR level. A followup patch will be needed to let backend understands `nomerge` and avoid tail merge at backend. Reviewed By: asbirlea, rnk Differential Revision: https://reviews.llvm.org/D78659
2020-05-13 05:07:50 +08:00
if (hasAttribute(Attribute::NoMerge))
return "nomerge";
Add 'nonnull', a new parameter and return attribute which indicates that the pointer is not null. Instcombine will elide comparisons between these and null. Patch by Luqman Aden! llvm-svn: 209185
2014-05-20 09:23:40 +08:00
if (hasAttribute(Attribute::NonNull))
return "nonnull";
Add support for emitting a string attribute. Attributes that are strings are typically target-dependent attributes. They are of this form in the IR: "attr" "attr" = "val" llvm-svn: 174090
2013-02-01 04:59:05 +08:00
if (hasAttribute(Attribute::NoRedZone))
return "noredzone";
if (hasAttribute(Attribute::NoReturn))
return "noreturn";
[Attributor] Deduce "nosync" function attribute. Introduce and deduce "nosync" function attribute to indicate that a function does not synchronize with another thread in a way that other thread might free memory. Reviewers: jdoerfert, jfb, nhaehnle, arsenm Subscribers: wdng, hfinkel, nhaenhle, mehdi_amini, steven_wu, dexonsmith, arsenm, uenoku, hiraditya, jfb, llvm-commits Differential Revision: https://reviews.llvm.org/D62766 llvm-svn: 365830
2019-07-12 05:37:40 +08:00
if (hasAttribute(Attribute::NoSync))
return "nosync";
[IR] Convert null-pointer-is-valid into an enum attribute The "null-pointer-is-valid" attribute needs to be checked by many pointer-related combines. To make the check more efficient, convert it from a string into an enum attribute. In the future, this attribute may be replaced with data layout properties. Differential Revision: https://reviews.llvm.org/D78862
2020-04-25 18:57:07 +08:00
if (hasAttribute(Attribute::NullPointerIsValid))
return "null_pointer_is_valid";
[Attr] Add "willreturn" function attribute This patch introduces a new function attribute, willreturn, to indicate that a call of this function will either exhibit undefined behavior or comes back and continues execution at a point in the existing call stack that includes the current invocation. This attribute guarantees that the function does not have any endless loops, endless recursion, or terminating functions like abort or exit. Patch by Hideto Ueno (@uenoku) Reviewers: jdoerfert Subscribers: mehdi_amini, hiraditya, steven_wu, dexonsmith, lebedev.ri, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D62801 llvm-svn: 364555
2019-06-27 23:51:40 +08:00
if (hasAttribute(Attribute::WillReturn))
return "willreturn";
[X86] Added support for nocf_check attribute for indirect Branch Tracking X86 Supports Indirect Branch Tracking (IBT) as part of Control-Flow Enforcement Technology (CET). IBT instruments ENDBR instructions used to specify valid targets of indirect call / jmp. The `nocf_check` attribute has two roles in the context of X86 IBT technology: 1. Appertains to a function - do not add ENDBR instruction at the beginning of the function. 2. Appertains to a function pointer - do not track the target function of this pointer by adding nocf_check prefix to the indirect-call instruction. This patch implements `nocf_check` context for Indirect Branch Tracking. It also auto generates `nocf_check` prefixes before indirect branchs to jump tables that are guarded by range checks. Differential Revision: https://reviews.llvm.org/D41879 llvm-svn: 327767
2018-03-17 21:29:46 +08:00
if (hasAttribute(Attribute::NoCfCheck))
return "nocf_check";
Add a new attribute: norecurse This attribute allows the compiler to assume that the function never recurses into itself, either directly or indirectly (transitively). This can be used among other things to demote global variables to locals. llvm-svn: 252282
2015-11-06 18:32:53 +08:00
if (hasAttribute(Attribute::NoRecurse))
return "norecurse";
Support for instrumenting only selected files or functions This change implements support for applying profile instrumentation only to selected files or functions. The implementation uses the sanitizer special case list format to select which files and functions to instrument, and relies on the new noprofile IR attribute to exclude functions from instrumentation. Differential Revision: https://reviews.llvm.org/D94820
2021-01-15 17:14:37 +08:00
if (hasAttribute(Attribute::NoProfile))
return "noprofile";
Add support for emitting a string attribute. Attributes that are strings are typically target-dependent attributes. They are of this form in the IR: "attr" "attr" = "val" llvm-svn: 174090
2013-02-01 04:59:05 +08:00
if (hasAttribute(Attribute::NoUnwind))
return "nounwind";
[SimplifyCFG] Create attribute for fuzzing-specific optimizations. Summary: When building with libFuzzer, converting control flow to selects or obscuring the original operands of CMPs reduces the effectiveness of libFuzzer's heuristics. This patch provides an attribute to disable or modify certain optimizations for optimal fuzzing signal. Provides a less aggressive alternative to https://reviews.llvm.org/D44057. Reviewers: vitalybuka, davide, arsenm, hfinkel Reviewed By: vitalybuka Subscribers: junbuml, mehdi_amini, wdng, javed.absar, hiraditya, llvm-commits, kcc Differential Revision: https://reviews.llvm.org/D44232 llvm-svn: 328214
2018-03-23 01:07:51 +08:00
if (hasAttribute(Attribute::OptForFuzzing))
return "optforfuzzing";
Add function attribute 'optnone'. This function attribute indicates that the function is not optimized by any optimization or code generator passes with the exception of interprocedural optimization passes. llvm-svn: 189101
2013-08-23 19:53:55 +08:00
if (hasAttribute(Attribute::OptimizeNone))
return "optnone";
Add support for emitting a string attribute. Attributes that are strings are typically target-dependent attributes. They are of this form in the IR: "attr" "attr" = "val" llvm-svn: 174090
2013-02-01 04:59:05 +08:00
if (hasAttribute(Attribute::OptimizeForSize))
return "optsize";
Rename the 'Attributes' class to 'Attribute'. It's going to represent a single attribute in the future. llvm-svn: 170502
2012-12-19 15:18:57 +08:00
if (hasAttribute(Attribute::ReadNone))
Convert getAttributes() to return an AttributeSetNode. The AttributeSetNode contains all of the attributes. This removes one (hopefully last) use of the Attribute class as a container of multiple attributes. llvm-svn: 173761
2013-01-29 11:20:31 +08:00
return "readnone";
Rename the 'Attributes' class to 'Attribute'. It's going to represent a single attribute in the future. llvm-svn: 170502
2012-12-19 15:18:57 +08:00
if (hasAttribute(Attribute::ReadOnly))
Convert getAttributes() to return an AttributeSetNode. The AttributeSetNode contains all of the attributes. This removes one (hopefully last) use of the Attribute class as a container of multiple attributes. llvm-svn: 173761
2013-01-29 11:20:31 +08:00
return "readonly";
Add writeonly IR attribute Summary: This complements the earlier addition of IntrWriteMem and IntrWriteArgMem LLVM intrinsic properties, see D18291. Also start using the attribute for memset, memcpy, and memmove intrinsics, and remove their special-casing in BasicAliasAnalysis. Reviewers: reames, joker.eph Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D18714 llvm-svn: 274485
2016-07-04 16:01:29 +08:00
if (hasAttribute(Attribute::WriteOnly))
return "writeonly";
Add CodeGen support for functions that always return arguments via a new parameter attribute 'returned', which is taken advantage of in target-independent tail call opportunity detection and in ARM call lowering (when placed on an integral first parameter). llvm-svn: 179925
2013-04-20 13:14:40 +08:00
if (hasAttribute(Attribute::Returned))
return "returned";
Add support for emitting a string attribute. Attributes that are strings are typically target-dependent attributes. They are of this form in the IR: "attr" "attr" = "val" llvm-svn: 174090
2013-02-01 04:59:05 +08:00
if (hasAttribute(Attribute::ReturnsTwice))
return "returns_twice";
if (hasAttribute(Attribute::SExt))
return "signext";
[x86/SLH] Add a real Clang flag and LLVM IR attribute for Speculative Load Hardening. Wires up the existing pass to work with a proper IR attribute rather than just a hidden/internal flag. The internal flag continues to work for now, but I'll likely remove it soon. Most of the churn here is adding the IR attribute. I talked about this Kristof Beyls and he seemed at least initially OK with this direction. The idea of using a full attribute here is that we *do* expect at least some forms of this for other architectures. There isn't anything *inherently* x86-specific about this technique, just that we only have an implementation for x86 at the moment. While we could potentially expose this as a Clang-level attribute as well, that seems like a good question to defer for the moment as it isn't 100% clear whether that or some other programmer interface (or both?) would be best. We'll defer the programmer interface side of this for now, but at least get to the point where the feature can be enabled without relying on implementation details. This also allows us to do something that was really hard before: we can enable *just* the indirect call retpolines when using SLH. For x86, we don't have any other way to mitigate indirect calls. Other architectures may take a different approach of course, and none of this is surfaced to user-level flags. Differential Revision: https://reviews.llvm.org/D51157 llvm-svn: 341363
2018-09-04 20:38:00 +08:00
if (hasAttribute(Attribute::SpeculativeLoadHardening))
return "speculative_load_hardening";
Add speculatable function attribute This attribute tells the optimizer that the function may be speculated. Patch by Tom Stellard llvm-svn: 301680
2017-04-29 04:25:27 +08:00
if (hasAttribute(Attribute::Speculatable))
return "speculatable";
Rename the 'Attributes' class to 'Attribute'. It's going to represent a single attribute in the future. llvm-svn: 170502
2012-12-19 15:18:57 +08:00
if (hasAttribute(Attribute::StackProtect))
Convert getAttributes() to return an AttributeSetNode. The AttributeSetNode contains all of the attributes. This removes one (hopefully last) use of the Attribute class as a container of multiple attributes. llvm-svn: 173761
2013-01-29 11:20:31 +08:00
return "ssp";
Rename the 'Attributes' class to 'Attribute'. It's going to represent a single attribute in the future. llvm-svn: 170502
2012-12-19 15:18:57 +08:00
if (hasAttribute(Attribute::StackProtectReq))
Convert getAttributes() to return an AttributeSetNode. The AttributeSetNode contains all of the attributes. This removes one (hopefully last) use of the Attribute class as a container of multiple attributes. llvm-svn: 173761
2013-01-29 11:20:31 +08:00
return "sspreq";
Add the IR attribute 'sspstrong'. SSPStrong applies a heuristic to insert stack protectors in these situations: * A Protector is required for functions which contain an array, regardless of type or length. * A Protector is required for functions which contain a structure/union which contains an array, regardless of type or length. Note, there is no limit to the depth of nesting. * A protector is required when the address of a local variable (i.e., stack based variable) is exposed. (E.g., such as through a local whose address is taken as part of the RHS of an assignment or a local whose address is taken as part of a function argument.) This patch implements the SSPString attribute to be equivalent to SSPRequired. This will change in a subsequent patch. llvm-svn: 173230
2013-01-23 14:41:41 +08:00
if (hasAttribute(Attribute::StackProtectStrong))
Convert getAttributes() to return an AttributeSetNode. The AttributeSetNode contains all of the attributes. This removes one (hopefully last) use of the Attribute class as a container of multiple attributes. llvm-svn: 173761
2013-01-29 11:20:31 +08:00
return "sspstrong";
Protection against stack-based memory corruption errors using SafeStack This patch adds the safe stack instrumentation pass to LLVM, which separates the program stack into a safe stack, which stores return addresses, register spills, and local variables that are statically verified to be accessed in a safe way, and the unsafe stack, which stores everything else. Such separation makes it much harder for an attacker to corrupt objects on the safe stack, including function pointers stored in spilled registers and return addresses. You can find more information about the safe stack, as well as other parts of or control-flow hijack protection technique in our OSDI paper on code-pointer integrity (http://dslab.epfl.ch/pubs/cpi.pdf) and our project website (http://levee.epfl.ch). The overhead of our implementation of the safe stack is very close to zero (0.01% on the Phoronix benchmarks). This is lower than the overhead of stack cookies, which are supported by LLVM and are commonly used today, yet the security guarantees of the safe stack are strictly stronger than stack cookies. In some cases, the safe stack improves performance due to better cache locality. Our current implementation of the safe stack is stable and robust, we used it to recompile multiple projects on Linux including Chromium, and we also recompiled the entire FreeBSD user-space system and more than 100 packages. We ran unit tests on the FreeBSD system and many of the packages and observed no errors caused by the safe stack. The safe stack is also fully binary compatible with non-instrumented code and can be applied to parts of a program selectively. This patch is our implementation of the safe stack on top of LLVM. The patches make the following changes: - Add the safestack function attribute, similar to the ssp, sspstrong and sspreq attributes. - Add the SafeStack instrumentation pass that applies the safe stack to all functions that have the safestack attribute. This pass moves all unsafe local variables to the unsafe stack with a separate stack pointer, whereas all safe variables remain on the regular stack that is managed by LLVM as usual. - Invoke the pass as the last stage before code generation (at the same time the existing cookie-based stack protector pass is invoked). - Add unit tests for the safe stack. Original patch by Volodymyr Kuznetsov and others at the Dependable Systems Lab at EPFL; updates and upstreaming by myself. Differential Revision: http://reviews.llvm.org/D6094 llvm-svn: 239761
2015-06-16 05:07:11 +08:00
if (hasAttribute(Attribute::SafeStack))
return "safestack";
Add the ShadowCallStack attribute Summary: Introduce the ShadowCallStack function attribute. It's added to functions compiled with -fsanitize=shadow-call-stack in order to mark functions to be instrumented by a ShadowCallStack pass to be submitted in a separate change. Reviewers: pcc, kcc, kubamracek Reviewed By: pcc, kcc Subscribers: cryptoad, mehdi_amini, javed.absar, llvm-commits, kcc Differential Revision: https://reviews.llvm.org/D44800 llvm-svn: 329108
2018-04-04 04:10:40 +08:00
if (hasAttribute(Attribute::ShadowCallStack))
return "shadowcallstack";
Add strictfp attribute to prevent unwanted optimizations of libm calls Differential Revision: https://reviews.llvm.org/D34163 llvm-svn: 310885
2017-08-15 05:15:13 +08:00
if (hasAttribute(Attribute::StrictFP))
return "strictfp";
Unify clang/llvm attributes for asan/tsan/msan (LLVM part) These are two related changes (one in llvm, one in clang). LLVM: - rename address_safety => sanitize_address (the enum value is the same, so we preserve binary compatibility with old bitcode) - rename thread_safety => sanitize_thread - rename no_uninitialized_checks -> sanitize_memory CLANG: - add __attribute__((no_sanitize_address)) as a synonym for __attribute__((no_address_safety_analysis)) - add __attribute__((no_sanitize_thread)) - add __attribute__((no_sanitize_memory)) for S in address thread memory If -fsanitize=S is present and __attribute__((no_sanitize_S)) is not set llvm attribute sanitize_S llvm-svn: 176075
2013-02-26 14:58:09 +08:00
if (hasAttribute(Attribute::SanitizeThread))
return "sanitize_thread";
if (hasAttribute(Attribute::SanitizeMemory))
return "sanitize_memory";
Add support for emitting a string attribute. Attributes that are strings are typically target-dependent attributes. They are of this form in the IR: "attr" "attr" = "val" llvm-svn: 174090
2013-02-01 04:59:05 +08:00
if (hasAttribute(Attribute::UWTable))
return "uwtable";
if (hasAttribute(Attribute::ZExt))
return "zeroext";
Add a new function attribute 'cold' to functions. Other than recognizing the attribute, the patch does little else. It changes the branch probability analyzer so that edges into blocks postdominated by a cold function are given low weight. Added analysis and code generation tests. Added documentation for the new attribute. llvm-svn: 182638
2013-05-24 20:26:52 +08:00
if (hasAttribute(Attribute::Cold))
return "cold";
[IR][PGO] Add hot func attribute and use hot/cold attribute in func section Clang FE currently has hot/cold function attribute. But we only have cold function attribute in LLVM IR. This patch adds support of hot function attribute to LLVM IR. This attribute will be used in setting function section prefix/suffix. Currently .hot and .unlikely suffix only are added in PGO (Sample PGO) compilation (through isFunctionHotInCallGraph and isFunctionColdInCallGraph). This patch changes the behavior. The new behavior is: (1) If the user annotates a function as hot or isFunctionHotInCallGraph is true, this function will be marked as hot. Otherwise, (2) If the user annotates a function as cold or isFunctionColdInCallGraph is true, this function will be marked as cold. The changes are: (1) user annotated function attribute will used in setting function section prefix/suffix. (2) hot attribute overwrites profile count based hotness. (3) profile count based hotness overwrite user annotated cold attribute. The intention for these changes is to provide the user a way to mark certain function as hot in cases where training input is hard to cover all the hot functions. Differential Revision: https://reviews.llvm.org/D92493
2020-12-18 09:30:41 +08:00
if (hasAttribute(Attribute::Hot))
return "hot";
IR: Add immarg attribute This indicates an intrinsic parameter is required to be a constant, and should not be replaced with a non-constant value. Add the attribute to all AMDGPU and generic intrinsics that comments indicate it should apply to. I scanned other target intrinsics, but I don't see any obvious comments indicating which arguments are intended to be only immediates. This breaks one questionable testcase for the autoupgrade. I'm unclear on whether the autoupgrade is supposed to really handle declarations which were never valid. The verifier fails because the attributes now refer to a parameter past the end of the argument list. llvm-svn: 355981
2019-03-13 05:02:54 +08:00
if (hasAttribute(Attribute::ImmArg))
return "immarg";
[LLVM] Accept `noundef` attribute in function definitions/calls The `noundef` attribute indicates an argument or return value which may never have an undef value representation. This patch allows LLVM to parse the attribute. Differential Revision: https://reviews.llvm.org/D83412
2020-07-09 01:22:48 +08:00
if (hasAttribute(Attribute::NoUndef))
return "noundef";
[IR] Adds mustprogress as a LLVM IR attribute This adds the LLVM IR attribute `mustprogress` as defined in LangRef through D86233. This attribute will be applied to functions with in languages like C++ where forward progress is guaranteed. Functions without this attribute are not required to make progress. Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D85393
2020-10-20 14:48:18 +08:00
if (hasAttribute(Attribute::MustProgress))
return "mustprogress";
Add support for emitting a string attribute. Attributes that are strings are typically target-dependent attributes. They are of this form in the IR: "attr" "attr" = "val" llvm-svn: 174090
2013-02-01 04:59:05 +08:00
Reapply "OpaquePtr: Add type to sret attribute" This reverts commit eb9f7c28e5fe6d75fed3587023e17f2997c8024b. Previously this was incorrectly handling linking of the contained type, so this merges the fixes from D88973.
2020-09-29 21:33:55 +08:00
const bool IsByVal = hasAttribute(Attribute::ByVal);
if (IsByVal || hasAttribute(Attribute::StructRet)) {
Reapply: IR: add optional type to 'byval' function parameters When we switch to opaque pointer types we will need some way to describe how many bytes a 'byval' parameter should occupy on the stack. This adds a (for now) optional extra type parameter. If present, the type must match the pointee type of the argument. The original commit did not remap byval types when linking modules, which broke LTO. This version fixes that. Note to front-end maintainers: if this causes test failures, it's probably because the "byval" attribute is printed after attributes without any parameter after this change. llvm-svn: 362128
2019-05-31 02:48:23 +08:00
std::string Result;
Reapply "OpaquePtr: Add type to sret attribute" This reverts commit eb9f7c28e5fe6d75fed3587023e17f2997c8024b. Previously this was incorrectly handling linking of the contained type, so this merges the fixes from D88973.
2020-09-29 21:33:55 +08:00
Result += IsByVal ? "byval" : "sret";
Reapply: IR: add optional type to 'byval' function parameters When we switch to opaque pointer types we will need some way to describe how many bytes a 'byval' parameter should occupy on the stack. This adds a (for now) optional extra type parameter. If present, the type must match the pointee type of the argument. The original commit did not remap byval types when linking modules, which broke LTO. This version fixes that. Note to front-end maintainers: if this causes test failures, it's probably because the "byval" attribute is printed after attributes without any parameter after this change. llvm-svn: 362128
2019-05-31 02:48:23 +08:00
if (Type *Ty = getValueAsType()) {
raw_string_ostream OS(Result);
Result += '(';
Ty->print(OS, false, true);
OS.flush();
Result += ')';
}
return Result;
}
IR: Define byref parameter attribute This allows tracking the in-memory type of a pointer argument to a function for ABI purposes. This is essentially a stripped down version of byval to remove some of the stack-copy implications in its definition. This includes the base IR changes, and some tests for places where it should be treated similarly to byval. Codegen support will be in a future patch. My original attempt at solving some of these problems was to repurpose byval with a different address space from the stack. However, it is technically permitted for the callee to introduce a write to the argument, although nothing does this in reality. There is also talk of removing and replacing the byval attribute, so a new attribute would need to take its place anyway. This is intended avoid some optimization issues with the current handling of aggregate arguments, as well as fixes inflexibilty in how frontends can specify the kernel ABI. The most honest representation of the amdgpu_kernel convention is to expose all kernel arguments as loads from constant memory. Today, these are raw, SSA Argument values and codegen is responsible for turning these into loads. Background: There currently isn't a satisfactory way to represent how arguments for the amdgpu_kernel calling convention are passed. In reality, arguments are passed in a single, flat, constant memory buffer implicitly passed to the function. It is also illegal to call this function in the IR, and this is only ever invoked by a driver of some kind. It does not make sense to have a stack passed parameter in this context as is implied by byval. It is never valid to write to the kernel arguments, as this would corrupt the inputs seen by other dispatches of the kernel. These argumets are also not in the same address space as the stack, so a copy is needed to an alloca. From a source C-like language, the kernel parameters are invisible. Semantically, a copy is always required from the constant argument memory to a mutable variable. The current clang calling convention lowering emits raw values, including aggregates into the function argument list, since using byval would not make sense. This has some unfortunate consequences for the optimizer. In the aggregate case, we end up with an aggregate store to alloca, which both SROA and instcombine turn into a store of each aggregate field. The optimizer never pieces this back together to see that this is really just a copy from constant memory, so we end up stuck with expensive stack usage. This also means the backend dictates the alignment of arguments, and arbitrarily picks the LLVM IR ABI type alignment. By allowing an explicit alignment, frontends can make better decisions. For example, there's real no advantage to an aligment higher than 4, so a frontend could choose to compact the argument layout. Similarly, there is a high penalty to using an alignment lower than 4, so a frontend could opt into more padding for small arguments. Another design consideration is when it is appropriate to expose the fact that these arguments are all really passed in adjacent memory. Currently we have a late IR optimization pass in codegen to rewrite the kernel argument values into explicit loads to enable vectorization. In most programs, unrelated argument loads can be merged together. However, exposing this property directly from the frontend has some disadvantages. We still need a way to track the original argument sizes and alignments to report to the driver. I find using some side-channel, metadata mechanism to track this unappealing. If the kernel arguments were exposed as a single buffer to begin with, alias analysis would be unaware that the padding bits betewen arguments are meaningless. Another family of problems is there are still some gaps in replacing all of the available parameter attributes with metadata equivalents once lowered to loads. The immediate plan is to start using this new attribute to handle all aggregate argumets for kernels. Long term, it makes sense to migrate all kernel arguments, including scalars, to be passed indirectly in the same manner. Additional context is in D79744.
2020-06-06 04:58:47 +08:00
const bool IsByRef = hasAttribute(Attribute::ByRef);
if (IsByRef || hasAttribute(Attribute::Preallocated)) {
std::string Result = IsByRef ? "byref" : "preallocated";
Add IR constructs for preallocated (inalloca replacement) Add llvm.call.preallocated.{setup,arg} instrinsics. Add "preallocated" operand bundle which takes a token produced by llvm.call.preallocated.setup. Add "preallocated" parameter attribute, which is like byval but without the copy. Verifier changes for these IR constructs. See https://github.com/rnk/llvm-project/blob/call-setup-docs/llvm/docs/CallSetup.md Subscribers: hiraditya, jdoerfert, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D74651
2020-02-15 06:16:53 +08:00
raw_string_ostream OS(Result);
Result += '(';
getValueAsType()->print(OS, false, true);
OS.flush();
Result += ')';
return Result;
}
Add support for emitting a string attribute. Attributes that are strings are typically target-dependent attributes. They are of this form in the IR: "attr" "attr" = "val" llvm-svn: 174090
2013-02-01 04:59:05 +08:00
// FIXME: These should be output like this:
//
// align=4
// alignstack=8
//
Convert to storing the attribute's internals as enums, integers, and strings. The stuff we're handing are all enums (Attribute::AttrKind), integers and strings. Don't convert them to Constants, which is an unnecessary step here. The rest of the changes are mostly mechanical. llvm-svn: 174456
2013-02-06 06:37:24 +08:00
if (hasAttribute(Attribute::Alignment)) {
Convert getAttributes() to return an AttributeSetNode. The AttributeSetNode contains all of the attributes. This removes one (hopefully last) use of the Attribute class as a container of multiple attributes. llvm-svn: 173761
2013-01-29 11:20:31 +08:00
std::string Result;
Add support for printing out the attribute groups. This emits the attribute groups that are used by the functions. (It currently doesn't print out return type or parameter attributes within attribute groups.) Note: The functions still retrieve their attributes from the "old" bitcode format (using the deprecated 'Raw()' method). This means that string attributes within an attribute group will not show up during a disassembly. This will be addressed in a future commit. llvm-svn: 174867
2013-02-11 16:43:33 +08:00
Result += "align";
Result += (InAttrGrp) ? "=" : " ";
Convert to storing the attribute's internals as enums, integers, and strings. The stuff we're handing are all enums (Attribute::AttrKind), integers and strings. Don't convert them to Constants, which is an unnecessary step here. The rest of the changes are mostly mechanical. llvm-svn: 174456
2013-02-06 06:37:24 +08:00
Result += utostr(getValueAsInt());
Convert getAttributes() to return an AttributeSetNode. The AttributeSetNode contains all of the attributes. This removes one (hopefully last) use of the Attribute class as a container of multiple attributes. llvm-svn: 173761
2013-01-29 11:20:31 +08:00
return Result;
Add a new function attribute, 'alignstack'. It will indicate (when the backends implement support for it) that the stack should be forcibly realigned in the prologue (and the process reversed in the epilogue). llvm-svn: 95945
2010-02-12 08:31:15 +08:00
}
Add support for printing out the attribute groups. This emits the attribute groups that are used by the functions. (It currently doesn't print out return type or parameter attributes within attribute groups.) Note: The functions still retrieve their attributes from the "old" bitcode format (using the deprecated 'Raw()' method). This means that string attributes within an attribute group will not show up during a disassembly. This will be addressed in a future commit. llvm-svn: 174867
2013-02-11 16:43:33 +08:00
[IR] Introduce a dereferenceable_or_null(N) attribute. Summary: If a pointer is marked as dereferenceable_or_null(N), LLVM assumes it is either `null` or `dereferenceable(N)` or both. This change only introduces the attribute and adds a token test case for the `llvm-as` / `llvm-dis`. It does not hook up other parts of the optimizer to actually exploit the attribute -- those changes will come later. For pointers in address space 0, `dereferenceable(N)` is now exactly equivalent to `dereferenceable_or_null(N)` && `nonnull`. For other address spaces, `dereferenceable(N)` is potentially weaker than `dereferenceable_or_null(N)` && `nonnull` (since we could have a null `dereferenceable(N)` pointer). The motivating case for this change is Java (and other managed languages), where pointers are either `null` or dereferenceable up to some usually known-at-compile-time constant offset. Reviewers: rafael, hfinkel Reviewed By: hfinkel Subscribers: nicholas, llvm-commits Differential Revision: http://reviews.llvm.org/D8650 llvm-svn: 235132
2015-04-17 04:29:50 +08:00
auto AttrWithBytesToString = [&](const char *Name) {
Convert getAttributes() to return an AttributeSetNode. The AttributeSetNode contains all of the attributes. This removes one (hopefully last) use of the Attribute class as a container of multiple attributes. llvm-svn: 173761
2013-01-29 11:20:31 +08:00
std::string Result;
[IR] Introduce a dereferenceable_or_null(N) attribute. Summary: If a pointer is marked as dereferenceable_or_null(N), LLVM assumes it is either `null` or `dereferenceable(N)` or both. This change only introduces the attribute and adds a token test case for the `llvm-as` / `llvm-dis`. It does not hook up other parts of the optimizer to actually exploit the attribute -- those changes will come later. For pointers in address space 0, `dereferenceable(N)` is now exactly equivalent to `dereferenceable_or_null(N)` && `nonnull`. For other address spaces, `dereferenceable(N)` is potentially weaker than `dereferenceable_or_null(N)` && `nonnull` (since we could have a null `dereferenceable(N)` pointer). The motivating case for this change is Java (and other managed languages), where pointers are either `null` or dereferenceable up to some usually known-at-compile-time constant offset. Reviewers: rafael, hfinkel Reviewed By: hfinkel Subscribers: nicholas, llvm-commits Differential Revision: http://reviews.llvm.org/D8650 llvm-svn: 235132
2015-04-17 04:29:50 +08:00
Result += Name;
Add support for printing out the attribute groups. This emits the attribute groups that are used by the functions. (It currently doesn't print out return type or parameter attributes within attribute groups.) Note: The functions still retrieve their attributes from the "old" bitcode format (using the deprecated 'Raw()' method). This means that string attributes within an attribute group will not show up during a disassembly. This will be addressed in a future commit. llvm-svn: 174867
2013-02-11 16:43:33 +08:00
if (InAttrGrp) {
Result += "=";
Result += utostr(getValueAsInt());
} else {
Result += "(";
Result += utostr(getValueAsInt());
Result += ")";
}
Convert getAttributes() to return an AttributeSetNode. The AttributeSetNode contains all of the attributes. This removes one (hopefully last) use of the Attribute class as a container of multiple attributes. llvm-svn: 173761
2013-01-29 11:20:31 +08:00
return Result;
[IR] Introduce a dereferenceable_or_null(N) attribute. Summary: If a pointer is marked as dereferenceable_or_null(N), LLVM assumes it is either `null` or `dereferenceable(N)` or both. This change only introduces the attribute and adds a token test case for the `llvm-as` / `llvm-dis`. It does not hook up other parts of the optimizer to actually exploit the attribute -- those changes will come later. For pointers in address space 0, `dereferenceable(N)` is now exactly equivalent to `dereferenceable_or_null(N)` && `nonnull`. For other address spaces, `dereferenceable(N)` is potentially weaker than `dereferenceable_or_null(N)` && `nonnull` (since we could have a null `dereferenceable(N)` pointer). The motivating case for this change is Java (and other managed languages), where pointers are either `null` or dereferenceable up to some usually known-at-compile-time constant offset. Reviewers: rafael, hfinkel Reviewed By: hfinkel Subscribers: nicholas, llvm-commits Differential Revision: http://reviews.llvm.org/D8650 llvm-svn: 235132
2015-04-17 04:29:50 +08:00
};
Add support for emitting a string attribute. Attributes that are strings are typically target-dependent attributes. They are of this form in the IR: "attr" "attr" = "val" llvm-svn: 174090
2013-02-01 04:59:05 +08:00
[IR] Introduce a dereferenceable_or_null(N) attribute. Summary: If a pointer is marked as dereferenceable_or_null(N), LLVM assumes it is either `null` or `dereferenceable(N)` or both. This change only introduces the attribute and adds a token test case for the `llvm-as` / `llvm-dis`. It does not hook up other parts of the optimizer to actually exploit the attribute -- those changes will come later. For pointers in address space 0, `dereferenceable(N)` is now exactly equivalent to `dereferenceable_or_null(N)` && `nonnull`. For other address spaces, `dereferenceable(N)` is potentially weaker than `dereferenceable_or_null(N)` && `nonnull` (since we could have a null `dereferenceable(N)` pointer). The motivating case for this change is Java (and other managed languages), where pointers are either `null` or dereferenceable up to some usually known-at-compile-time constant offset. Reviewers: rafael, hfinkel Reviewed By: hfinkel Subscribers: nicholas, llvm-commits Differential Revision: http://reviews.llvm.org/D8650 llvm-svn: 235132
2015-04-17 04:29:50 +08:00
if (hasAttribute(Attribute::StackAlignment))
return AttrWithBytesToString("alignstack");
if (hasAttribute(Attribute::Dereferenceable))
return AttrWithBytesToString("dereferenceable");
if (hasAttribute(Attribute::DereferenceableOrNull))
return AttrWithBytesToString("dereferenceable_or_null");
Add a dereferenceable attribute This attribute indicates that the parameter or return pointer is dereferenceable. Practically speaking, loads from such a pointer within the associated byte range are safe to speculatively execute. Such pointer parameters are common in source languages (C++ references, for example). llvm-svn: 213385
2014-07-18 23:51:28 +08:00
Add the allocsize attribute to LLVM. `allocsize` is a function attribute that allows users to request that LLVM treat arbitrary functions as allocation functions. This patch makes LLVM accept the `allocsize` attribute, and makes `@llvm.objectsize` recognize said attribute. The review for this was split into two patches for ease of reviewing: D18974 and D14933. As promised on the revisions, I'm landing both patches as a single commit. Differential Revision: http://reviews.llvm.org/D14933 llvm-svn: 266032
2016-04-12 09:05:35 +08:00
if (hasAttribute(Attribute::AllocSize)) {
unsigned ElemSize;
Optional<unsigned> NumElems;
std::tie(ElemSize, NumElems) = getAllocSizeArgs();
std::string Result = "allocsize(";
Result += utostr(ElemSize);
if (NumElems.hasValue()) {
Result += ',';
Result += utostr(*NumElems);
}
Result += ')';
return Result;
}
Add support for emitting a string attribute. Attributes that are strings are typically target-dependent attributes. They are of this form in the IR: "attr" "attr" = "val" llvm-svn: 174090
2013-02-01 04:59:05 +08:00
// Convert target-dependent attributes to strings of the form:
//
// "kind"
// "kind" = "value"
//
Convert to storing the attribute's internals as enums, integers, and strings. The stuff we're handing are all enums (Attribute::AttrKind), integers and strings. Don't convert them to Constants, which is an unnecessary step here. The rest of the changes are mostly mechanical. llvm-svn: 174456
2013-02-06 06:37:24 +08:00
if (isStringAttribute()) {
Add support for emitting a string attribute. Attributes that are strings are typically target-dependent attributes. They are of this form in the IR: "attr" "attr" = "val" llvm-svn: 174090
2013-02-01 04:59:05 +08:00
std::string Result;
[IR] Properly handle escape characters in Attribute::getAsString() If an attribute name has special characters such as '\01', it is not properly printed in LLVM assembly language format. Since the format expects the special characters are printed as it is, it has to contain escape characters to make it printable. Before: attributes #0 = { ... "counting-function"="^A__gnu_mcount_nc" ... After: attributes #0 = { ... "counting-function"="\01__gnu_mcount_nc" ... Reviewers: hfinkel, rengolin, rjmccall, compnerd Subscribers: nemanjai, mcrosier, hans, shenhan, majnemer, llvm-commits Differential Revision: https://reviews.llvm.org/D23792 llvm-svn: 280357
2016-09-01 19:44:06 +08:00
{
raw_string_ostream OS(Result);
[IR] Simplify code to print string attributes a bit. NFC.
2020-04-26 19:06:50 +08:00
OS << '"' << getKindAsString() << '"';
// Since some attribute strings contain special characters that cannot be
// printable, those have to be escaped to make the attribute value
// printable as is. e.g. "\01__gnu_mcount_nc"
const auto &AttrVal = pImpl->getValueAsString();
if (!AttrVal.empty()) {
OS << "=\"";
printEscapedString(AttrVal, OS);
OS << "\"";
}
[IR] Properly handle escape characters in Attribute::getAsString() If an attribute name has special characters such as '\01', it is not properly printed in LLVM assembly language format. Since the format expects the special characters are printed as it is, it has to contain escape characters to make it printable. Before: attributes #0 = { ... "counting-function"="^A__gnu_mcount_nc" ... After: attributes #0 = { ... "counting-function"="\01__gnu_mcount_nc" ... Reviewers: hfinkel, rengolin, rjmccall, compnerd Subscribers: nemanjai, mcrosier, hans, shenhan, majnemer, llvm-commits Differential Revision: https://reviews.llvm.org/D23792 llvm-svn: 280357
2016-09-01 19:44:06 +08:00
}
Remove some dead code, improve some asserts, and other assorted changes. No functionality change. llvm-svn: 174132
2013-02-01 09:04:27 +08:00
return Result;
Add support for emitting a string attribute. Attributes that are strings are typically target-dependent attributes. They are of this form in the IR: "attr" "attr" = "val" llvm-svn: 174090
2013-02-01 04:59:05 +08:00
}
Convert getAttributes() to return an AttributeSetNode. The AttributeSetNode contains all of the attributes. This removes one (hopefully last) use of the Attribute class as a container of multiple attributes. llvm-svn: 173761
2013-01-29 11:20:31 +08:00
llvm_unreachable("Unknown attribute");
Split param attr implementation out from Function.cpp into its own file. Don't #include ParameterAttributes.h into any major public header files: just move methods out of line as appropriate. llvm-svn: 45517
2008-01-03 07:42:30 +08:00
}
Reorder some functions and add comments. No functionality change. llvm-svn: 173733
2013-01-29 08:34:06 +08:00
bool Attribute::operator<(Attribute A) const {
if (!pImpl && !A.pImpl) return false;
if (!pImpl) return true;
if (!A.pImpl) return false;
return *pImpl < *A.pImpl;
Use the Attributes::Builder to build the attributes in the parser. llvm-svn: 165458
2012-10-09 07:27:46 +08:00
}
Remove unneeded FoldingSet.h include from Attributes.h Avoids 637 extra FoldingSet.h and Allocator.h includes. FoldingSet.h needs Allocator.h, which is relatively expensive.
2020-01-18 08:04:02 +08:00
void Attribute::Profile(FoldingSetNodeID &ID) const {
ID.AddPointer(pImpl);
}
Initial commit for the AttributesImpl class. This opaque class will contain all of the attributes. All attribute queries will go through this object. This object will also be uniqued in the LLVMContext. Currently not used, so no implementation change. llvm-svn: 164722
2012-09-27 05:07:29 +08:00
//===----------------------------------------------------------------------===//
// AttributeImpl Definition
//===----------------------------------------------------------------------===//
Convert to storing the attribute's internals as enums, integers, and strings. The stuff we're handing are all enums (Attribute::AttrKind), integers and strings. Don't convert them to Constants, which is an unnecessary step here. The rest of the changes are mostly mechanical. llvm-svn: 174456
2013-02-06 06:37:24 +08:00
bool AttributeImpl::hasAttribute(Attribute::AttrKind A) const {
if (isStringAttribute()) return false;
return getKindAsEnum() == A;
Add a few (as yet unused) query methods to determine if the attribute that's stored here is of a certain kind. This is in preparation for when an Attribute object represents a single attribute, instead of a bitmask of attributes. llvm-svn: 171247
2012-12-30 09:38:39 +08:00
}
Create a new class: AttributeSetNode. This is a helper class for the AttributeSetImpl class. It holds a set of attributes that apply to a single element: function, return type, or parameter. These are uniqued. llvm-svn: 173310
2013-01-24 08:06:56 +08:00
Convert to storing the attribute's internals as enums, integers, and strings. The stuff we're handing are all enums (Attribute::AttrKind), integers and strings. Don't convert them to Constants, which is an unnecessary step here. The rest of the changes are mostly mechanical. llvm-svn: 174456
2013-02-06 06:37:24 +08:00
bool AttributeImpl::hasAttribute(StringRef Kind) const {
if (!isStringAttribute()) return false;
return getKindAsString() == Kind;
General cleanups. * Remove dead methods. * Use the 'operator==' method instead of 'contains', which isn't needed. * Fix some comments. No functionality change. llvm-svn: 171523
2013-01-05 04:54:35 +08:00
}
Add a few (as yet unused) query methods to determine if the attribute that's stored here is of a certain kind. This is in preparation for when an Attribute object represents a single attribute, instead of a bitmask of attributes. llvm-svn: 171247
2012-12-30 09:38:39 +08:00
Convert to storing the attribute's internals as enums, integers, and strings. The stuff we're handing are all enums (Attribute::AttrKind), integers and strings. Don't convert them to Constants, which is an unnecessary step here. The rest of the changes are mostly mechanical. llvm-svn: 174456
2013-02-06 06:37:24 +08:00
Attribute::AttrKind AttributeImpl::getKindAsEnum() const {
Reapply: IR: add optional type to 'byval' function parameters When we switch to opaque pointer types we will need some way to describe how many bytes a 'byval' parameter should occupy on the stack. This adds a (for now) optional extra type parameter. If present, the type must match the pointee type of the argument. The original commit did not remap byval types when linking modules, which broke LTO. This version fixes that. Note to front-end maintainers: if this causes test failures, it's probably because the "byval" attribute is printed after attributes without any parameter after this change. llvm-svn: 362128
2019-05-31 02:48:23 +08:00
assert(isEnumAttribute() || isIntAttribute() || isTypeAttribute());
Reduce the number of indirections in the attributes implementation. - Coallocate entires for AttributeSetImpls and Nodes after the class itself. - Remove mutable iterators from immutable classes. - Remove unused context field from AttributeImpl. - Derive Enum/Align/String attribute implementations from AttributeImpl instead of having a whole new inheritance tree for them. - Derive AlignAttributeImpl from EnumAttributeImpl. llvm-svn: 186075
2013-07-11 20:13:16 +08:00
return static_cast<const EnumAttributeImpl *>(this)->getEnumKind();
Convert to storing the attribute's internals as enums, integers, and strings. The stuff we're handing are all enums (Attribute::AttrKind), integers and strings. Don't convert them to Constants, which is an unnecessary step here. The rest of the changes are mostly mechanical. llvm-svn: 174456
2013-02-06 06:37:24 +08:00
}
Remove some dead code, improve some asserts, and other assorted changes. No functionality change. llvm-svn: 174132
2013-02-01 09:04:27 +08:00
Convert to storing the attribute's internals as enums, integers, and strings. The stuff we're handing are all enums (Attribute::AttrKind), integers and strings. Don't convert them to Constants, which is an unnecessary step here. The rest of the changes are mostly mechanical. llvm-svn: 174456
2013-02-06 06:37:24 +08:00
uint64_t AttributeImpl::getValueAsInt() const {
Rename AlignAttribute to IntAttribute Currently the only kind of integer IR attributes that we have are alignment attributes, and so the attribute kind that takes an integer parameter is called AlignAttr, but that will change (we'll soon be adding a dereferenceable attribute that also takes an integer value). Accordingly, rename AlignAttribute to IntAttribute (class names, enums, etc.). No functionality change intended. llvm-svn: 213352
2014-07-18 14:51:55 +08:00
assert(isIntAttribute());
return static_cast<const IntAttributeImpl *>(this)->getValue();
Convert to storing the attribute's internals as enums, integers, and strings. The stuff we're handing are all enums (Attribute::AttrKind), integers and strings. Don't convert them to Constants, which is an unnecessary step here. The rest of the changes are mostly mechanical. llvm-svn: 174456
2013-02-06 06:37:24 +08:00
}
Create a new class: AttributeSetNode. This is a helper class for the AttributeSetImpl class. It holds a set of attributes that apply to a single element: function, return type, or parameter. These are uniqued. llvm-svn: 173310
2013-01-24 08:06:56 +08:00
Convert to storing the attribute's internals as enums, integers, and strings. The stuff we're handing are all enums (Attribute::AttrKind), integers and strings. Don't convert them to Constants, which is an unnecessary step here. The rest of the changes are mostly mechanical. llvm-svn: 174456
2013-02-06 06:37:24 +08:00
StringRef AttributeImpl::getKindAsString() const {
Reduce the number of indirections in the attributes implementation. - Coallocate entires for AttributeSetImpls and Nodes after the class itself. - Remove mutable iterators from immutable classes. - Remove unused context field from AttributeImpl. - Derive Enum/Align/String attribute implementations from AttributeImpl instead of having a whole new inheritance tree for them. - Derive AlignAttributeImpl from EnumAttributeImpl. llvm-svn: 186075
2013-07-11 20:13:16 +08:00
assert(isStringAttribute());
return static_cast<const StringAttributeImpl *>(this)->getStringKind();
Convert to storing the attribute's internals as enums, integers, and strings. The stuff we're handing are all enums (Attribute::AttrKind), integers and strings. Don't convert them to Constants, which is an unnecessary step here. The rest of the changes are mostly mechanical. llvm-svn: 174456
2013-02-06 06:37:24 +08:00
}
Create a new class: AttributeSetNode. This is a helper class for the AttributeSetImpl class. It holds a set of attributes that apply to a single element: function, return type, or parameter. These are uniqued. llvm-svn: 173310
2013-01-24 08:06:56 +08:00
Convert to storing the attribute's internals as enums, integers, and strings. The stuff we're handing are all enums (Attribute::AttrKind), integers and strings. Don't convert them to Constants, which is an unnecessary step here. The rest of the changes are mostly mechanical. llvm-svn: 174456
2013-02-06 06:37:24 +08:00
StringRef AttributeImpl::getValueAsString() const {
Reduce the number of indirections in the attributes implementation. - Coallocate entires for AttributeSetImpls and Nodes after the class itself. - Remove mutable iterators from immutable classes. - Remove unused context field from AttributeImpl. - Derive Enum/Align/String attribute implementations from AttributeImpl instead of having a whole new inheritance tree for them. - Derive AlignAttributeImpl from EnumAttributeImpl. llvm-svn: 186075
2013-07-11 20:13:16 +08:00
assert(isStringAttribute());
return static_cast<const StringAttributeImpl *>(this)->getStringValue();
Convert to storing the attribute's internals as enums, integers, and strings. The stuff we're handing are all enums (Attribute::AttrKind), integers and strings. Don't convert them to Constants, which is an unnecessary step here. The rest of the changes are mostly mechanical. llvm-svn: 174456
2013-02-06 06:37:24 +08:00
}
Create a new class: AttributeSetNode. This is a helper class for the AttributeSetImpl class. It holds a set of attributes that apply to a single element: function, return type, or parameter. These are uniqued. llvm-svn: 173310
2013-01-24 08:06:56 +08:00
Reapply: IR: add optional type to 'byval' function parameters When we switch to opaque pointer types we will need some way to describe how many bytes a 'byval' parameter should occupy on the stack. This adds a (for now) optional extra type parameter. If present, the type must match the pointee type of the argument. The original commit did not remap byval types when linking modules, which broke LTO. This version fixes that. Note to front-end maintainers: if this causes test failures, it's probably because the "byval" attribute is printed after attributes without any parameter after this change. llvm-svn: 362128
2019-05-31 02:48:23 +08:00
Type *AttributeImpl::getValueAsType() const {
assert(isTypeAttribute());
return static_cast<const TypeAttributeImpl *>(this)->getTypeValue();
}
Convert to storing the attribute's internals as enums, integers, and strings. The stuff we're handing are all enums (Attribute::AttrKind), integers and strings. Don't convert them to Constants, which is an unnecessary step here. The rest of the changes are mostly mechanical. llvm-svn: 174456
2013-02-06 06:37:24 +08:00
bool AttributeImpl::operator<(const AttributeImpl &AI) const {
[IR] Short-circuit comparison with itself for Attributes Differential Revision: https://reviews.llvm.org/D82295
2020-06-23 19:43:02 +08:00
if (this == &AI)
return false;
Convert to storing the attribute's internals as enums, integers, and strings. The stuff we're handing are all enums (Attribute::AttrKind), integers and strings. Don't convert them to Constants, which is an unnecessary step here. The rest of the changes are mostly mechanical. llvm-svn: 174456
2013-02-06 06:37:24 +08:00
// This sorts the attributes with Attribute::AttrKinds coming first (sorted
// relative to their enum value) and then strings.
Simplify the 'operator<' for the attribute object. llvm-svn: 175252
2013-02-15 13:25:26 +08:00
if (isEnumAttribute()) {
if (AI.isEnumAttribute()) return getKindAsEnum() < AI.getKindAsEnum();
Rename AlignAttribute to IntAttribute Currently the only kind of integer IR attributes that we have are alignment attributes, and so the attribute kind that takes an integer parameter is called AlignAttr, but that will change (we'll soon be adding a dereferenceable attribute that also takes an integer value). Accordingly, rename AlignAttribute to IntAttribute (class names, enums, etc.). No functionality change intended. llvm-svn: 213352
2014-07-18 14:51:55 +08:00
if (AI.isIntAttribute()) return true;
Simplify the 'operator<' for the attribute object. llvm-svn: 175252
2013-02-15 13:25:26 +08:00
if (AI.isStringAttribute()) return true;
Reapply: IR: add optional type to 'byval' function parameters When we switch to opaque pointer types we will need some way to describe how many bytes a 'byval' parameter should occupy on the stack. This adds a (for now) optional extra type parameter. If present, the type must match the pointee type of the argument. The original commit did not remap byval types when linking modules, which broke LTO. This version fixes that. Note to front-end maintainers: if this causes test failures, it's probably because the "byval" attribute is printed after attributes without any parameter after this change. llvm-svn: 362128
2019-05-31 02:48:23 +08:00
if (AI.isTypeAttribute()) return true;
}
if (isTypeAttribute()) {
if (AI.isEnumAttribute()) return false;
if (AI.isTypeAttribute()) {
assert(getKindAsEnum() != AI.getKindAsEnum() &&
"Comparison of types would be unstable");
return getKindAsEnum() < AI.getKindAsEnum();
}
if (AI.isIntAttribute()) return true;
if (AI.isStringAttribute()) return true;
Revert "Simplify the attributes '<' comparison function." This reverts commit 82c101153fe7b35bce48781fab038e1b8f31a7bd. llvm-svn: 175250
2013-02-15 12:15:55 +08:00
}
Rename AlignAttribute to IntAttribute Currently the only kind of integer IR attributes that we have are alignment attributes, and so the attribute kind that takes an integer parameter is called AlignAttr, but that will change (we'll soon be adding a dereferenceable attribute that also takes an integer value). Accordingly, rename AlignAttribute to IntAttribute (class names, enums, etc.). No functionality change intended. llvm-svn: 213352
2014-07-18 14:51:55 +08:00
if (isIntAttribute()) {
Simplify the 'operator<' for the attribute object. llvm-svn: 175252
2013-02-15 13:25:26 +08:00
if (AI.isEnumAttribute()) return false;
Reapply: IR: add optional type to 'byval' function parameters When we switch to opaque pointer types we will need some way to describe how many bytes a 'byval' parameter should occupy on the stack. This adds a (for now) optional extra type parameter. If present, the type must match the pointee type of the argument. The original commit did not remap byval types when linking modules, which broke LTO. This version fixes that. Note to front-end maintainers: if this causes test failures, it's probably because the "byval" attribute is printed after attributes without any parameter after this change. llvm-svn: 362128
2019-05-31 02:48:23 +08:00
if (AI.isTypeAttribute()) return false;
Fix non-determinism in order of LLVM attributes We were using array_pod_sort on an array of type 'Attribute', which wraps a pointer to AttributeImpl. For the most part this didn't matter because the printing code prints enum attributes in a defined order, but integer attributes such as 'align' and 'dereferenceable' were not ordered. Furthermore, AttributeImpl::operator< was broken for integer attributes. An integer attribute is a kind and an integer value, and both pieces need to be compared. By fixing the comparison operator, we can go back to std::sort, and things look good now. This should fix clang arm-swiftcall.c test failures on Windows. llvm-svn: 265361
2016-04-05 07:06:05 +08:00
if (AI.isIntAttribute()) {
if (getKindAsEnum() == AI.getKindAsEnum())
return getValueAsInt() < AI.getValueAsInt();
return getKindAsEnum() < AI.getKindAsEnum();
}
Simplify the 'operator<' for the attribute object. llvm-svn: 175252
2013-02-15 13:25:26 +08:00
if (AI.isStringAttribute()) return true;
Convert to storing the attribute's internals as enums, integers, and strings. The stuff we're handing are all enums (Attribute::AttrKind), integers and strings. Don't convert them to Constants, which is an unnecessary step here. The rest of the changes are mostly mechanical. llvm-svn: 174456
2013-02-06 06:37:24 +08:00
}
Create a new class: AttributeSetNode. This is a helper class for the AttributeSetImpl class. It holds a set of attributes that apply to a single element: function, return type, or parameter. These are uniqued. llvm-svn: 173310
2013-01-24 08:06:56 +08:00
Reapply: IR: add optional type to 'byval' function parameters When we switch to opaque pointer types we will need some way to describe how many bytes a 'byval' parameter should occupy on the stack. This adds a (for now) optional extra type parameter. If present, the type must match the pointee type of the argument. The original commit did not remap byval types when linking modules, which broke LTO. This version fixes that. Note to front-end maintainers: if this causes test failures, it's probably because the "byval" attribute is printed after attributes without any parameter after this change. llvm-svn: 362128
2019-05-31 02:48:23 +08:00
assert(isStringAttribute());
Simplify the 'operator<' for the attribute object. llvm-svn: 175252
2013-02-15 13:25:26 +08:00
if (AI.isEnumAttribute()) return false;
Reapply: IR: add optional type to 'byval' function parameters When we switch to opaque pointer types we will need some way to describe how many bytes a 'byval' parameter should occupy on the stack. This adds a (for now) optional extra type parameter. If present, the type must match the pointee type of the argument. The original commit did not remap byval types when linking modules, which broke LTO. This version fixes that. Note to front-end maintainers: if this causes test failures, it's probably because the "byval" attribute is printed after attributes without any parameter after this change. llvm-svn: 362128
2019-05-31 02:48:23 +08:00
if (AI.isTypeAttribute()) return false;
Rename AlignAttribute to IntAttribute Currently the only kind of integer IR attributes that we have are alignment attributes, and so the attribute kind that takes an integer parameter is called AlignAttr, but that will change (we'll soon be adding a dereferenceable attribute that also takes an integer value). Accordingly, rename AlignAttribute to IntAttribute (class names, enums, etc.). No functionality change intended. llvm-svn: 213352
2014-07-18 14:51:55 +08:00
if (AI.isIntAttribute()) return false;
Simplify the 'operator<' for the attribute object. llvm-svn: 175252
2013-02-15 13:25:26 +08:00
if (getKindAsString() == AI.getKindAsString())
return getValueAsString() < AI.getValueAsString();
return getKindAsString() < AI.getKindAsString();
Create a new class: AttributeSetNode. This is a helper class for the AttributeSetImpl class. It holds a set of attributes that apply to a single element: function, return type, or parameter. These are uniqued. llvm-svn: 173310
2013-01-24 08:06:56 +08:00
}
[IR] Add AttributeSet to hide AttributeSetNode* again, NFC Summary: For now, it just wraps AttributeSetNode*. Eventually, it will hold AvailableAttrs as an inline bitset, and adding and removing enum attributes will be super cheap. This sinks AttributeSetNode back down to lib/IR/AttributeImpl.h. Reviewers: pete, chandlerc Subscribers: llvm-commits, jfb Differential Revision: https://reviews.llvm.org/D31940 llvm-svn: 300014
2017-04-12 08:38:00 +08:00
//===----------------------------------------------------------------------===//
// AttributeSet Definition
//===----------------------------------------------------------------------===//
AttributeSet AttributeSet::get(LLVMContext &C, const AttrBuilder &B) {
return AttributeSet(AttributeSetNode::get(C, B));
}
AttributeSet AttributeSet::get(LLVMContext &C, ArrayRef<Attribute> Attrs) {
return AttributeSet(AttributeSetNode::get(C, Attrs));
}
[IR] Allow attributes with global variables This patch extends llvm-ir to allow attributes to be set on global variables. An RFC was sent out earlier by my colleague James Molloy: http://lists.llvm.org/pipermail/cfe-dev/2017-March/053100.html A key part of that proposal was to extend LLVM-IR to carry attributes on global variables. This generic feature could be useful for multiple purposes. In our present context, it would be useful to carry user specified sections for bss/rodata/data. Reviewed by: Jonathan Roelofs, Reid Kleckner Differential Revision: https://reviews.llvm.org/D32009 llvm-svn: 302794
2017-05-11 20:28:08 +08:00
AttributeSet AttributeSet::addAttribute(LLVMContext &C,
[IR] Switch AttributeList to use an array for O(1) access Summary: Before this change, AttributeLists stored a pair of index and AttributeSet. This is memory efficient if most arguments do not have attributes. However, it requires doing a search over the pairs to test an argument or function attribute. Profiling shows that this loop was 0.76% of the time in 'opt -O2' of sqlite3.c, because LLVM constantly tests values for nullability. This was worth about 2.5% of mid-level optimization cycles on the sqlite3 amalgamation. Here are the full perf results: https://reviews.llvm.org/P7995 Here are just the before and after cycle counts: ``` $ perf stat -r 5 ./opt_before -O2 sqlite3.bc -o /dev/null 13,274,181,184 cycles # 3.047 GHz ( +- 0.28% ) $ perf stat -r 5 ./opt_after -O2 sqlite3.bc -o /dev/null 12,906,927,263 cycles # 3.043 GHz ( +- 0.51% ) ``` This patch *does not* change the indices used to query attributes, as requested by reviewers. Tracking whether an index is usable for array indexing is a huge pain that affects many of the internal APIs, so it would be good to come back later and do a cleanup to remove this internal adjustment. Reviewers: pete, chandlerc Subscribers: javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D32819 llvm-svn: 303654
2017-05-24 01:01:48 +08:00
Attribute::AttrKind Kind) const {
[IR] Allow attributes with global variables This patch extends llvm-ir to allow attributes to be set on global variables. An RFC was sent out earlier by my colleague James Molloy: http://lists.llvm.org/pipermail/cfe-dev/2017-March/053100.html A key part of that proposal was to extend LLVM-IR to carry attributes on global variables. This generic feature could be useful for multiple purposes. In our present context, it would be useful to carry user specified sections for bss/rodata/data. Reviewed by: Jonathan Roelofs, Reid Kleckner Differential Revision: https://reviews.llvm.org/D32009 llvm-svn: 302794
2017-05-11 20:28:08 +08:00
if (hasAttribute(Kind)) return *this;
AttrBuilder B;
B.addAttribute(Kind);
return addAttributes(C, AttributeSet::get(C, B));
}
AttributeSet AttributeSet::addAttribute(LLVMContext &C, StringRef Kind,
[IR] Switch AttributeList to use an array for O(1) access Summary: Before this change, AttributeLists stored a pair of index and AttributeSet. This is memory efficient if most arguments do not have attributes. However, it requires doing a search over the pairs to test an argument or function attribute. Profiling shows that this loop was 0.76% of the time in 'opt -O2' of sqlite3.c, because LLVM constantly tests values for nullability. This was worth about 2.5% of mid-level optimization cycles on the sqlite3 amalgamation. Here are the full perf results: https://reviews.llvm.org/P7995 Here are just the before and after cycle counts: ``` $ perf stat -r 5 ./opt_before -O2 sqlite3.bc -o /dev/null 13,274,181,184 cycles # 3.047 GHz ( +- 0.28% ) $ perf stat -r 5 ./opt_after -O2 sqlite3.bc -o /dev/null 12,906,927,263 cycles # 3.043 GHz ( +- 0.51% ) ``` This patch *does not* change the indices used to query attributes, as requested by reviewers. Tracking whether an index is usable for array indexing is a huge pain that affects many of the internal APIs, so it would be good to come back later and do a cleanup to remove this internal adjustment. Reviewers: pete, chandlerc Subscribers: javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D32819 llvm-svn: 303654
2017-05-24 01:01:48 +08:00
StringRef Value) const {
[IR] Allow attributes with global variables This patch extends llvm-ir to allow attributes to be set on global variables. An RFC was sent out earlier by my colleague James Molloy: http://lists.llvm.org/pipermail/cfe-dev/2017-March/053100.html A key part of that proposal was to extend LLVM-IR to carry attributes on global variables. This generic feature could be useful for multiple purposes. In our present context, it would be useful to carry user specified sections for bss/rodata/data. Reviewed by: Jonathan Roelofs, Reid Kleckner Differential Revision: https://reviews.llvm.org/D32009 llvm-svn: 302794
2017-05-11 20:28:08 +08:00
AttrBuilder B;
B.addAttribute(Kind, Value);
return addAttributes(C, AttributeSet::get(C, B));
}
AttributeSet AttributeSet::addAttributes(LLVMContext &C,
const AttributeSet AS) const {
if (!hasAttributes())
return AS;
if (!AS.hasAttributes())
return *this;
AttrBuilder B(AS);
[IR] Use a reference in a range-based for This avoids unneeded copies when using a range-based for loops. This avoids new warnings due to D68912 adds -Wrange-loop-analysis to -Wall. Differential Revision: https://reviews.llvm.org/D70870
2019-12-18 04:57:58 +08:00
for (const auto &I : *this)
[IR] Allow attributes with global variables This patch extends llvm-ir to allow attributes to be set on global variables. An RFC was sent out earlier by my colleague James Molloy: http://lists.llvm.org/pipermail/cfe-dev/2017-March/053100.html A key part of that proposal was to extend LLVM-IR to carry attributes on global variables. This generic feature could be useful for multiple purposes. In our present context, it would be useful to carry user specified sections for bss/rodata/data. Reviewed by: Jonathan Roelofs, Reid Kleckner Differential Revision: https://reviews.llvm.org/D32009 llvm-svn: 302794
2017-05-11 20:28:08 +08:00
B.addAttribute(I);
return get(C, B);
}
AttributeSet AttributeSet::removeAttribute(LLVMContext &C,
Attribute::AttrKind Kind) const {
if (!hasAttribute(Kind)) return *this;
[Attributes] Fix crash when attempting to remove alignment from an attribute list/set Summary: Discovered while working on a patch to move alignment in @llvm.memcpy/move/set from an arg into parameter attributes. The current implementations of AttributeSet::removeAttribute() and AttributeList::removeAttribute crash when attempting to remove the alignment attribute. Currently, these implementations add the to-be-removed attributes to an AttrBuilder and then remove the builder from the list/set. Alignment is special in that it must be added to a builder with an integer value for the alignment; attempts to add alignment to a builder without a value is an error. This change fixes the removeAttribute implementations for AttributeSet and AttributeList to make them able to remove the alignment, and other similar, attributes. Reviewers: rnk, chandlerc, pete, javed.absar, reames Reviewed By: rnk Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D41951 llvm-svn: 322735
2018-01-18 03:15:21 +08:00
AttrBuilder B(*this);
B.removeAttribute(Kind);
return get(C, B);
[IR] Allow attributes with global variables This patch extends llvm-ir to allow attributes to be set on global variables. An RFC was sent out earlier by my colleague James Molloy: http://lists.llvm.org/pipermail/cfe-dev/2017-March/053100.html A key part of that proposal was to extend LLVM-IR to carry attributes on global variables. This generic feature could be useful for multiple purposes. In our present context, it would be useful to carry user specified sections for bss/rodata/data. Reviewed by: Jonathan Roelofs, Reid Kleckner Differential Revision: https://reviews.llvm.org/D32009 llvm-svn: 302794
2017-05-11 20:28:08 +08:00
}
AttributeSet AttributeSet::removeAttribute(LLVMContext &C,
StringRef Kind) const {
if (!hasAttribute(Kind)) return *this;
[Attributes] Fix crash when attempting to remove alignment from an attribute list/set Summary: Discovered while working on a patch to move alignment in @llvm.memcpy/move/set from an arg into parameter attributes. The current implementations of AttributeSet::removeAttribute() and AttributeList::removeAttribute crash when attempting to remove the alignment attribute. Currently, these implementations add the to-be-removed attributes to an AttrBuilder and then remove the builder from the list/set. Alignment is special in that it must be added to a builder with an integer value for the alignment; attempts to add alignment to a builder without a value is an error. This change fixes the removeAttribute implementations for AttributeSet and AttributeList to make them able to remove the alignment, and other similar, attributes. Reviewers: rnk, chandlerc, pete, javed.absar, reames Reviewed By: rnk Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D41951 llvm-svn: 322735
2018-01-18 03:15:21 +08:00
AttrBuilder B(*this);
B.removeAttribute(Kind);
return get(C, B);
[IR] Allow attributes with global variables This patch extends llvm-ir to allow attributes to be set on global variables. An RFC was sent out earlier by my colleague James Molloy: http://lists.llvm.org/pipermail/cfe-dev/2017-March/053100.html A key part of that proposal was to extend LLVM-IR to carry attributes on global variables. This generic feature could be useful for multiple purposes. In our present context, it would be useful to carry user specified sections for bss/rodata/data. Reviewed by: Jonathan Roelofs, Reid Kleckner Differential Revision: https://reviews.llvm.org/D32009 llvm-svn: 302794
2017-05-11 20:28:08 +08:00
}
AttributeSet AttributeSet::removeAttributes(LLVMContext &C,
const AttrBuilder &Attrs) const {
AttrBuilder B(*this);
B.remove(Attrs);
return get(C, B);
}
[IR] Add AttributeSet to hide AttributeSetNode* again, NFC Summary: For now, it just wraps AttributeSetNode*. Eventually, it will hold AvailableAttrs as an inline bitset, and adding and removing enum attributes will be super cheap. This sinks AttributeSetNode back down to lib/IR/AttributeImpl.h. Reviewers: pete, chandlerc Subscribers: llvm-commits, jfb Differential Revision: https://reviews.llvm.org/D31940 llvm-svn: 300014
2017-04-12 08:38:00 +08:00
unsigned AttributeSet::getNumAttributes() const {
return SetNode ? SetNode->getNumAttributes() : 0;
}
bool AttributeSet::hasAttribute(Attribute::AttrKind Kind) const {
[IR] Fix some Clang-tidy modernize-use-using warnings; other minor fixes (NFC). llvm-svn: 303119
2017-05-16 05:57:41 +08:00
return SetNode ? SetNode->hasAttribute(Kind) : false;
[IR] Add AttributeSet to hide AttributeSetNode* again, NFC Summary: For now, it just wraps AttributeSetNode*. Eventually, it will hold AvailableAttrs as an inline bitset, and adding and removing enum attributes will be super cheap. This sinks AttributeSetNode back down to lib/IR/AttributeImpl.h. Reviewers: pete, chandlerc Subscribers: llvm-commits, jfb Differential Revision: https://reviews.llvm.org/D31940 llvm-svn: 300014
2017-04-12 08:38:00 +08:00
}
bool AttributeSet::hasAttribute(StringRef Kind) const {
[IR] Fix some Clang-tidy modernize-use-using warnings; other minor fixes (NFC). llvm-svn: 303119
2017-05-16 05:57:41 +08:00
return SetNode ? SetNode->hasAttribute(Kind) : false;
[IR] Add AttributeSet to hide AttributeSetNode* again, NFC Summary: For now, it just wraps AttributeSetNode*. Eventually, it will hold AvailableAttrs as an inline bitset, and adding and removing enum attributes will be super cheap. This sinks AttributeSetNode back down to lib/IR/AttributeImpl.h. Reviewers: pete, chandlerc Subscribers: llvm-commits, jfb Differential Revision: https://reviews.llvm.org/D31940 llvm-svn: 300014
2017-04-12 08:38:00 +08:00
}
Attribute AttributeSet::getAttribute(Attribute::AttrKind Kind) const {
return SetNode ? SetNode->getAttribute(Kind) : Attribute();
}
Attribute AttributeSet::getAttribute(StringRef Kind) const {
return SetNode ? SetNode->getAttribute(Kind) : Attribute();
}
[Alignment][NFC] Attributes use Align/MaybeAlign Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Subscribers: jholewinski, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69278 llvm-svn: 375495
2019-10-22 17:51:06 +08:00
MaybeAlign AttributeSet::getAlignment() const {
return SetNode ? SetNode->getAlignment() : None;
[IR] Add AttributeSet to hide AttributeSetNode* again, NFC Summary: For now, it just wraps AttributeSetNode*. Eventually, it will hold AvailableAttrs as an inline bitset, and adding and removing enum attributes will be super cheap. This sinks AttributeSetNode back down to lib/IR/AttributeImpl.h. Reviewers: pete, chandlerc Subscribers: llvm-commits, jfb Differential Revision: https://reviews.llvm.org/D31940 llvm-svn: 300014
2017-04-12 08:38:00 +08:00
}
[Alignment][NFC] Attributes use Align/MaybeAlign Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Subscribers: jholewinski, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69278 llvm-svn: 375495
2019-10-22 17:51:06 +08:00
MaybeAlign AttributeSet::getStackAlignment() const {
return SetNode ? SetNode->getStackAlignment() : None;
[IR] Add AttributeSet to hide AttributeSetNode* again, NFC Summary: For now, it just wraps AttributeSetNode*. Eventually, it will hold AvailableAttrs as an inline bitset, and adding and removing enum attributes will be super cheap. This sinks AttributeSetNode back down to lib/IR/AttributeImpl.h. Reviewers: pete, chandlerc Subscribers: llvm-commits, jfb Differential Revision: https://reviews.llvm.org/D31940 llvm-svn: 300014
2017-04-12 08:38:00 +08:00
}
uint64_t AttributeSet::getDereferenceableBytes() const {
return SetNode ? SetNode->getDereferenceableBytes() : 0;
}
uint64_t AttributeSet::getDereferenceableOrNullBytes() const {
return SetNode ? SetNode->getDereferenceableOrNullBytes() : 0;
}
IR: Define byref parameter attribute This allows tracking the in-memory type of a pointer argument to a function for ABI purposes. This is essentially a stripped down version of byval to remove some of the stack-copy implications in its definition. This includes the base IR changes, and some tests for places where it should be treated similarly to byval. Codegen support will be in a future patch. My original attempt at solving some of these problems was to repurpose byval with a different address space from the stack. However, it is technically permitted for the callee to introduce a write to the argument, although nothing does this in reality. There is also talk of removing and replacing the byval attribute, so a new attribute would need to take its place anyway. This is intended avoid some optimization issues with the current handling of aggregate arguments, as well as fixes inflexibilty in how frontends can specify the kernel ABI. The most honest representation of the amdgpu_kernel convention is to expose all kernel arguments as loads from constant memory. Today, these are raw, SSA Argument values and codegen is responsible for turning these into loads. Background: There currently isn't a satisfactory way to represent how arguments for the amdgpu_kernel calling convention are passed. In reality, arguments are passed in a single, flat, constant memory buffer implicitly passed to the function. It is also illegal to call this function in the IR, and this is only ever invoked by a driver of some kind. It does not make sense to have a stack passed parameter in this context as is implied by byval. It is never valid to write to the kernel arguments, as this would corrupt the inputs seen by other dispatches of the kernel. These argumets are also not in the same address space as the stack, so a copy is needed to an alloca. From a source C-like language, the kernel parameters are invisible. Semantically, a copy is always required from the constant argument memory to a mutable variable. The current clang calling convention lowering emits raw values, including aggregates into the function argument list, since using byval would not make sense. This has some unfortunate consequences for the optimizer. In the aggregate case, we end up with an aggregate store to alloca, which both SROA and instcombine turn into a store of each aggregate field. The optimizer never pieces this back together to see that this is really just a copy from constant memory, so we end up stuck with expensive stack usage. This also means the backend dictates the alignment of arguments, and arbitrarily picks the LLVM IR ABI type alignment. By allowing an explicit alignment, frontends can make better decisions. For example, there's real no advantage to an aligment higher than 4, so a frontend could choose to compact the argument layout. Similarly, there is a high penalty to using an alignment lower than 4, so a frontend could opt into more padding for small arguments. Another design consideration is when it is appropriate to expose the fact that these arguments are all really passed in adjacent memory. Currently we have a late IR optimization pass in codegen to rewrite the kernel argument values into explicit loads to enable vectorization. In most programs, unrelated argument loads can be merged together. However, exposing this property directly from the frontend has some disadvantages. We still need a way to track the original argument sizes and alignments to report to the driver. I find using some side-channel, metadata mechanism to track this unappealing. If the kernel arguments were exposed as a single buffer to begin with, alias analysis would be unaware that the padding bits betewen arguments are meaningless. Another family of problems is there are still some gaps in replacing all of the available parameter attributes with metadata equivalents once lowered to loads. The immediate plan is to start using this new attribute to handle all aggregate argumets for kernels. Long term, it makes sense to migrate all kernel arguments, including scalars, to be passed indirectly in the same manner. Additional context is in D79744.
2020-06-06 04:58:47 +08:00
Type *AttributeSet::getByRefType() const {
return SetNode ? SetNode->getByRefType() : nullptr;
}
Reapply: IR: add optional type to 'byval' function parameters When we switch to opaque pointer types we will need some way to describe how many bytes a 'byval' parameter should occupy on the stack. This adds a (for now) optional extra type parameter. If present, the type must match the pointee type of the argument. The original commit did not remap byval types when linking modules, which broke LTO. This version fixes that. Note to front-end maintainers: if this causes test failures, it's probably because the "byval" attribute is printed after attributes without any parameter after this change. llvm-svn: 362128
2019-05-31 02:48:23 +08:00
Type *AttributeSet::getByValType() const {
return SetNode ? SetNode->getByValType() : nullptr;
}
Reapply "OpaquePtr: Add type to sret attribute" This reverts commit eb9f7c28e5fe6d75fed3587023e17f2997c8024b. Previously this was incorrectly handling linking of the contained type, so this merges the fixes from D88973.
2020-09-29 21:33:55 +08:00
Type *AttributeSet::getStructRetType() const {
return SetNode ? SetNode->getStructRetType() : nullptr;
}
Add IR constructs for preallocated (inalloca replacement) Add llvm.call.preallocated.{setup,arg} instrinsics. Add "preallocated" operand bundle which takes a token produced by llvm.call.preallocated.setup. Add "preallocated" parameter attribute, which is like byval but without the copy. Verifier changes for these IR constructs. See https://github.com/rnk/llvm-project/blob/call-setup-docs/llvm/docs/CallSetup.md Subscribers: hiraditya, jdoerfert, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D74651
2020-02-15 06:16:53 +08:00
Type *AttributeSet::getPreallocatedType() const {
return SetNode ? SetNode->getPreallocatedType() : nullptr;
}
[IR] Add AttributeSet to hide AttributeSetNode* again, NFC Summary: For now, it just wraps AttributeSetNode*. Eventually, it will hold AvailableAttrs as an inline bitset, and adding and removing enum attributes will be super cheap. This sinks AttributeSetNode back down to lib/IR/AttributeImpl.h. Reviewers: pete, chandlerc Subscribers: llvm-commits, jfb Differential Revision: https://reviews.llvm.org/D31940 llvm-svn: 300014
2017-04-12 08:38:00 +08:00
std::pair<unsigned, Optional<unsigned>> AttributeSet::getAllocSizeArgs() const {
Fix compiler error in Attributes.cpp ``` Compiling Attributes.cpp ... ../../../Attributes.cpp: In member function 'std::__1::pair<unsigned int, llvm::Optional<unsigned int> > llvm::AttributeSet::getAllocSizeArgs() const': ../../../Attributes.cpp:542:69: error: operands to ?: have different types 'std::__1::pair<unsigned int, llvm::Optional<unsigned int> >' and 'std::__1::pair<int, int>' return SetNode ? SetNode->getAllocSizeArgs() : std::make_pair(0, 0); ^ ../../../Attributes.cpp:543:1: error: control reaches end of non-void function [-Werror=return-type] } ^ ``` Differential Revision: https://reviews.llvm.org/D31981 llvm-svn: 300143
2017-04-13 07:57:37 +08:00
return SetNode ? SetNode->getAllocSizeArgs()
: std::pair<unsigned, Optional<unsigned>>(0, 0);
[IR] Add AttributeSet to hide AttributeSetNode* again, NFC Summary: For now, it just wraps AttributeSetNode*. Eventually, it will hold AvailableAttrs as an inline bitset, and adding and removing enum attributes will be super cheap. This sinks AttributeSetNode back down to lib/IR/AttributeImpl.h. Reviewers: pete, chandlerc Subscribers: llvm-commits, jfb Differential Revision: https://reviews.llvm.org/D31940 llvm-svn: 300014
2017-04-12 08:38:00 +08:00
}
std::string AttributeSet::getAsString(bool InAttrGrp) const {
return SetNode ? SetNode->getAsString(InAttrGrp) : "";
}
AttributeSet::iterator AttributeSet::begin() const {
return SetNode ? SetNode->begin() : nullptr;
}
AttributeSet::iterator AttributeSet::end() const {
return SetNode ? SetNode->end() : nullptr;
}
Reverting r315590; it did not include changes for llvm-tblgen, which is causing link errors for several people. Error LNK2019 unresolved external symbol "public: void __cdecl `anonymous namespace'::MatchableInfo::dump(void)const " (?dump@MatchableInfo@?A0xf4f1c304@@QEBAXXZ) referenced in function "public: void __cdecl `anonymous namespace'::AsmMatcherEmitter::run(class llvm::raw_ostream &)" (?run@AsmMatcherEmitter@?A0xf4f1c304@@QEAAXAEAVraw_ostream@llvm@@@Z) llvm-tblgen D:\llvm\2017\utils\TableGen\AsmMatcherEmitter.obj 1 llvm-svn: 315854
2017-10-15 22:32:27 +08:00
#if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP)
[IR] Allow attributes with global variables This patch extends llvm-ir to allow attributes to be set on global variables. An RFC was sent out earlier by my colleague James Molloy: http://lists.llvm.org/pipermail/cfe-dev/2017-March/053100.html A key part of that proposal was to extend LLVM-IR to carry attributes on global variables. This generic feature could be useful for multiple purposes. In our present context, it would be useful to carry user specified sections for bss/rodata/data. Reviewed by: Jonathan Roelofs, Reid Kleckner Differential Revision: https://reviews.llvm.org/D32009 llvm-svn: 302794
2017-05-11 20:28:08 +08:00
LLVM_DUMP_METHOD void AttributeSet::dump() const {
dbgs() << "AS =\n";
dbgs() << " { ";
dbgs() << getAsString(true) << " }\n";
}
#endif
Create a new class: AttributeSetNode. This is a helper class for the AttributeSetImpl class. It holds a set of attributes that apply to a single element: function, return type, or parameter. These are uniqued. llvm-svn: 173310
2013-01-24 08:06:56 +08:00
//===----------------------------------------------------------------------===//
// AttributeSetNode Definition
//===----------------------------------------------------------------------===//
Remove AttributeSetNode::get(AttributeList, unsigned) and sink constructor The getter was equivalent to AttributeList::getAttributes(unsigned), which seems like a better way to express getting the AttributeSet for a given index. This static helper was only used in one place anyway. The constructor doesn't benefit from inlining and doesn't need to be in a header. llvm-svn: 299900
2017-04-11 07:46:08 +08:00
AttributeSetNode::AttributeSetNode(ArrayRef<Attribute> Attrs)
Extend function attributes bitset size from 64 to 96. Summary: We are going to add a function attribute number 64. Reviewers: pcc, jdoerfert, lebedev.ri Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64663 llvm-svn: 365980
2019-07-13 08:29:03 +08:00
: NumAttrs(Attrs.size()) {
Remove AttributeSetNode::get(AttributeList, unsigned) and sink constructor The getter was equivalent to AttributeList::getAttributes(unsigned), which seems like a better way to express getting the AttributeSet for a given index. This static helper was only used in one place anyway. The constructor doesn't benefit from inlining and doesn't need to be in a header. llvm-svn: 299900
2017-04-11 07:46:08 +08:00
// There's memory after the node where we can store the entries in.
Use llvm::copy. NFC llvm-svn: 347126
2018-11-17 09:44:25 +08:00
llvm::copy(Attrs, getTrailingObjects<Attribute>());
Remove AttributeSetNode::get(AttributeList, unsigned) and sink constructor The getter was equivalent to AttributeList::getAttributes(unsigned), which seems like a better way to express getting the AttributeSet for a given index. This static helper was only used in one place anyway. The constructor doesn't benefit from inlining and doesn't need to be in a header. llvm-svn: 299900
2017-04-11 07:46:08 +08:00
[IR] Use a reference in a range-based for This avoids unneeded copies when using a range-based for loops. This avoids new warnings due to D68912 adds -Wrange-loop-analysis to -Wall. Differential Revision: https://reviews.llvm.org/D70870
2019-12-18 04:57:58 +08:00
for (const auto &I : *this) {
[IR] Add AttributeBitSet wrapper (NFC) This wraps the uint8_t[12] type used in two places, because I plan to introduce a third use of the same pattern.
2020-06-15 05:46:18 +08:00
if (I.isStringAttribute())
[IR] Use map for string attributes (NFC) Attributes are currently stored as a simple list. Enum attributes additionally use a bitset to allow quickly determining whether an attribute is set. String attributes on the other hand require a full scan of the list. As functions tend to have a lot of string attributes (at least when clang is used), this is a noticeable performance issue. This patch adds an additional name => attribute map to the AttributeSetNode, which allows querying string attributes quickly. This results in a 3% reduction in instructions retired on CTMark. Changes to memory usage seem to be in the noise (attribute sets are uniqued, and we don't tend to have more than a few dozen or hundred unique attribute sets, so adding an extra map does not have a noticeable cost.) Differential Revision: https://reviews.llvm.org/D78859
2020-04-25 18:21:21 +08:00
StringAttrs.insert({ I.getKindAsString(), I });
[IR] Add AttributeBitSet wrapper (NFC) This wraps the uint8_t[12] type used in two places, because I plan to introduce a third use of the same pattern.
2020-06-15 05:46:18 +08:00
else
AvailableAttrs.addAttribute(I.getKindAsEnum());
Remove AttributeSetNode::get(AttributeList, unsigned) and sink constructor The getter was equivalent to AttributeList::getAttributes(unsigned), which seems like a better way to express getting the AttributeSet for a given index. This static helper was only used in one place anyway. The constructor doesn't benefit from inlining and doesn't need to be in a header. llvm-svn: 299900
2017-04-11 07:46:08 +08:00
}
}
Create a new class: AttributeSetNode. This is a helper class for the AttributeSetImpl class. It holds a set of attributes that apply to a single element: function, return type, or parameter. These are uniqued. llvm-svn: 173310
2013-01-24 08:06:56 +08:00
AttributeSetNode *AttributeSetNode::get(LLVMContext &C,
ArrayRef<Attribute> Attrs) {
Sort EnumAttr so it matches Attribute::operator< This means AttrBuilder will always create a sorted set of attributes and we can skip the sorting step. Sorting attributes is surprisingly expensive, and I recently made it worse by making it use array_pod_sort.
2020-04-26 22:52:53 +08:00
SmallVector<Attribute, 8> SortedAttrs(Attrs.begin(), Attrs.end());
llvm::sort(SortedAttrs);
return getSorted(C, SortedAttrs);
}
AttributeSetNode *AttributeSetNode::getSorted(LLVMContext &C,
ArrayRef<Attribute> SortedAttrs) {
if (SortedAttrs.empty())
[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
return nullptr;
Create a new class: AttributeSetNode. This is a helper class for the AttributeSetImpl class. It holds a set of attributes that apply to a single element: function, return type, or parameter. These are uniqued. llvm-svn: 173310
2013-01-24 08:06:56 +08:00
Sort EnumAttr so it matches Attribute::operator< This means AttrBuilder will always create a sorted set of attributes and we can skip the sorting step. Sorting attributes is surprisingly expensive, and I recently made it worse by making it use array_pod_sort.
2020-04-26 22:52:53 +08:00
// Build a key to look up the existing attributes.
Create a new class: AttributeSetNode. This is a helper class for the AttributeSetImpl class. It holds a set of attributes that apply to a single element: function, return type, or parameter. These are uniqued. llvm-svn: 173310
2013-01-24 08:06:56 +08:00
LLVMContextImpl *pImpl = C.pImpl;
FoldingSetNodeID ID;
Sort EnumAttr so it matches Attribute::operator< This means AttrBuilder will always create a sorted set of attributes and we can skip the sorting step. Sorting attributes is surprisingly expensive, and I recently made it worse by making it use array_pod_sort.
2020-04-26 22:52:53 +08:00
assert(llvm::is_sorted(SortedAttrs) && "Expected sorted attributes!");
[IR] Use a reference in a range-based for This avoids unneeded copies when using a range-based for loops. This avoids new warnings due to D68912 adds -Wrange-loop-analysis to -Wall. Differential Revision: https://reviews.llvm.org/D70870
2019-12-18 04:57:58 +08:00
for (const auto &Attr : SortedAttrs)
Minor cleanup of Attribute code. NFC. llvm-svn: 255751
2015-12-16 13:21:02 +08:00
Attr.Profile(ID);
Create a new class: AttributeSetNode. This is a helper class for the AttributeSetImpl class. It holds a set of attributes that apply to a single element: function, return type, or parameter. These are uniqued. llvm-svn: 173310
2013-01-24 08:06:56 +08:00
void *InsertPoint;
AttributeSetNode *PA =
pImpl->AttrsSetNodes.FindNodeOrInsertPos(ID, InsertPoint);
// If we didn't find any existing attributes of the same shape then create a
// new one and insert it.
if (!PA) {
Reduce the number of indirections in the attributes implementation. - Coallocate entires for AttributeSetImpls and Nodes after the class itself. - Remove mutable iterators from immutable classes. - Remove unused context field from AttributeImpl. - Derive Enum/Align/String attribute implementations from AttributeImpl instead of having a whole new inheritance tree for them. - Derive AlignAttributeImpl from EnumAttributeImpl. llvm-svn: 186075
2013-07-11 20:13:16 +08:00
// Coallocate entries after the AttributeSetNode itself.
Add a TrailingObjects template class. This is intended to help support the idiom of a class that has some other objects (or multiple arrays of different types of objects) appended on the end, which is used quite heavily in clang. Differential Revision: http://reviews.llvm.org/D11272 llvm-svn: 244164
2015-08-06 06:57:34 +08:00
void *Mem = ::operator new(totalSizeToAlloc<Attribute>(SortedAttrs.size()));
Reduce the number of indirections in the attributes implementation. - Coallocate entires for AttributeSetImpls and Nodes after the class itself. - Remove mutable iterators from immutable classes. - Remove unused context field from AttributeImpl. - Derive Enum/Align/String attribute implementations from AttributeImpl instead of having a whole new inheritance tree for them. - Derive AlignAttributeImpl from EnumAttributeImpl. llvm-svn: 186075
2013-07-11 20:13:16 +08:00
PA = new (Mem) AttributeSetNode(SortedAttrs);
Create a new class: AttributeSetNode. This is a helper class for the AttributeSetImpl class. It holds a set of attributes that apply to a single element: function, return type, or parameter. These are uniqued. llvm-svn: 173310
2013-01-24 08:06:56 +08:00
pImpl->AttrsSetNodes.InsertNode(PA, InsertPoint);
}
Rename AttributeSet to AttributeList Summary: This class is a list of AttributeSetNodes corresponding the function prototype of a call or function declaration. This class used to be called ParamAttrListPtr, then AttrListPtr, then AttributeSet. It is typically accessed by parameter and return value index, so "AttributeList" seems like a more intuitive name. Rename AttributeSetImpl to AttributeListImpl to follow suit. It's useful to rename this class so that we can rename AttributeSetNode to AttributeSet later. AttributeSet is the set of attributes that apply to a single function, argument, or return value. Reviewers: sanjoy, javed.absar, chandlerc, pete Reviewed By: pete Subscribers: pete, jholewinski, arsenm, dschuff, mehdi_amini, jfb, nhaehnle, sbc100, void, llvm-commits Differential Revision: https://reviews.llvm.org/D31102 llvm-svn: 298393
2017-03-22 00:57:19 +08:00
// Return the AttributeSetNode that we found or created.
Create a new class: AttributeSetNode. This is a helper class for the AttributeSetImpl class. It holds a set of attributes that apply to a single element: function, return type, or parameter. These are uniqued. llvm-svn: 173310
2013-01-24 08:06:56 +08:00
return PA;
}
Reland "[IR] Make AttributeSetNode public, avoid temporary AttributeList copies" This re-lands r299875. I introduced a bug in Clang code responsible for replacing K&R, no prototype declarations with a real function definition with a prototype. The bug was here: // Collect any return attributes from the call. - if (oldAttrs.hasAttributes(llvm::AttributeList::ReturnIndex)) - newAttrs.push_back(llvm::AttributeList::get(newFn->getContext(), - oldAttrs.getRetAttributes())); + newAttrs.push_back(oldAttrs.getRetAttributes()); Previously getRetAttributes() carried AttributeList::ReturnIndex in its AttributeList. Now that we return the AttributeSetNode* directly, it no longer carries that index, and we call this overload with a single node: AttributeList::get(LLVMContext&, ArrayRef<AttributeSetNode*>) That aborted with an assertion on x86_32 targets. I added an explicit triple to the test and added CHECKs to help find issues like this in the future sooner. llvm-svn: 299899
2017-04-11 07:31:05 +08:00
AttributeSetNode *AttributeSetNode::get(LLVMContext &C, const AttrBuilder &B) {
// Add target-independent attributes.
SmallVector<Attribute, 8> Attrs;
for (Attribute::AttrKind Kind = Attribute::None;
Kind != Attribute::EndAttrKinds; Kind = Attribute::AttrKind(Kind + 1)) {
if (!B.contains(Kind))
continue;
Attribute Attr;
switch (Kind) {
Reapply: IR: add optional type to 'byval' function parameters When we switch to opaque pointer types we will need some way to describe how many bytes a 'byval' parameter should occupy on the stack. This adds a (for now) optional extra type parameter. If present, the type must match the pointee type of the argument. The original commit did not remap byval types when linking modules, which broke LTO. This version fixes that. Note to front-end maintainers: if this causes test failures, it's probably because the "byval" attribute is printed after attributes without any parameter after this change. llvm-svn: 362128
2019-05-31 02:48:23 +08:00
case Attribute::ByVal:
Attr = Attribute::getWithByValType(C, B.getByValType());
break;
Reapply "OpaquePtr: Add type to sret attribute" This reverts commit eb9f7c28e5fe6d75fed3587023e17f2997c8024b. Previously this was incorrectly handling linking of the contained type, so this merges the fixes from D88973.
2020-09-29 21:33:55 +08:00
case Attribute::StructRet:
Attr = Attribute::getWithStructRetType(C, B.getStructRetType());
break;
IR: Define byref parameter attribute This allows tracking the in-memory type of a pointer argument to a function for ABI purposes. This is essentially a stripped down version of byval to remove some of the stack-copy implications in its definition. This includes the base IR changes, and some tests for places where it should be treated similarly to byval. Codegen support will be in a future patch. My original attempt at solving some of these problems was to repurpose byval with a different address space from the stack. However, it is technically permitted for the callee to introduce a write to the argument, although nothing does this in reality. There is also talk of removing and replacing the byval attribute, so a new attribute would need to take its place anyway. This is intended avoid some optimization issues with the current handling of aggregate arguments, as well as fixes inflexibilty in how frontends can specify the kernel ABI. The most honest representation of the amdgpu_kernel convention is to expose all kernel arguments as loads from constant memory. Today, these are raw, SSA Argument values and codegen is responsible for turning these into loads. Background: There currently isn't a satisfactory way to represent how arguments for the amdgpu_kernel calling convention are passed. In reality, arguments are passed in a single, flat, constant memory buffer implicitly passed to the function. It is also illegal to call this function in the IR, and this is only ever invoked by a driver of some kind. It does not make sense to have a stack passed parameter in this context as is implied by byval. It is never valid to write to the kernel arguments, as this would corrupt the inputs seen by other dispatches of the kernel. These argumets are also not in the same address space as the stack, so a copy is needed to an alloca. From a source C-like language, the kernel parameters are invisible. Semantically, a copy is always required from the constant argument memory to a mutable variable. The current clang calling convention lowering emits raw values, including aggregates into the function argument list, since using byval would not make sense. This has some unfortunate consequences for the optimizer. In the aggregate case, we end up with an aggregate store to alloca, which both SROA and instcombine turn into a store of each aggregate field. The optimizer never pieces this back together to see that this is really just a copy from constant memory, so we end up stuck with expensive stack usage. This also means the backend dictates the alignment of arguments, and arbitrarily picks the LLVM IR ABI type alignment. By allowing an explicit alignment, frontends can make better decisions. For example, there's real no advantage to an aligment higher than 4, so a frontend could choose to compact the argument layout. Similarly, there is a high penalty to using an alignment lower than 4, so a frontend could opt into more padding for small arguments. Another design consideration is when it is appropriate to expose the fact that these arguments are all really passed in adjacent memory. Currently we have a late IR optimization pass in codegen to rewrite the kernel argument values into explicit loads to enable vectorization. In most programs, unrelated argument loads can be merged together. However, exposing this property directly from the frontend has some disadvantages. We still need a way to track the original argument sizes and alignments to report to the driver. I find using some side-channel, metadata mechanism to track this unappealing. If the kernel arguments were exposed as a single buffer to begin with, alias analysis would be unaware that the padding bits betewen arguments are meaningless. Another family of problems is there are still some gaps in replacing all of the available parameter attributes with metadata equivalents once lowered to loads. The immediate plan is to start using this new attribute to handle all aggregate argumets for kernels. Long term, it makes sense to migrate all kernel arguments, including scalars, to be passed indirectly in the same manner. Additional context is in D79744.
2020-06-06 04:58:47 +08:00
case Attribute::ByRef:
Attr = Attribute::getWithByRefType(C, B.getByRefType());
break;
Add IR constructs for preallocated (inalloca replacement) Add llvm.call.preallocated.{setup,arg} instrinsics. Add "preallocated" operand bundle which takes a token produced by llvm.call.preallocated.setup. Add "preallocated" parameter attribute, which is like byval but without the copy. Verifier changes for these IR constructs. See https://github.com/rnk/llvm-project/blob/call-setup-docs/llvm/docs/CallSetup.md Subscribers: hiraditya, jdoerfert, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D74651
2020-02-15 06:16:53 +08:00
case Attribute::Preallocated:
Attr = Attribute::getWithPreallocatedType(C, B.getPreallocatedType());
break;
Reland "[IR] Make AttributeSetNode public, avoid temporary AttributeList copies" This re-lands r299875. I introduced a bug in Clang code responsible for replacing K&R, no prototype declarations with a real function definition with a prototype. The bug was here: // Collect any return attributes from the call. - if (oldAttrs.hasAttributes(llvm::AttributeList::ReturnIndex)) - newAttrs.push_back(llvm::AttributeList::get(newFn->getContext(), - oldAttrs.getRetAttributes())); + newAttrs.push_back(oldAttrs.getRetAttributes()); Previously getRetAttributes() carried AttributeList::ReturnIndex in its AttributeList. Now that we return the AttributeSetNode* directly, it no longer carries that index, and we call this overload with a single node: AttributeList::get(LLVMContext&, ArrayRef<AttributeSetNode*>) That aborted with an assertion on x86_32 targets. I added an explicit triple to the test and added CHECKs to help find issues like this in the future sooner. llvm-svn: 299899
2017-04-11 07:31:05 +08:00
case Attribute::Alignment:
[Alignment][NFC] Use MaybeAlign in AttrBuilder Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69300 llvm-svn: 375496
2019-10-22 19:57:52 +08:00
assert(B.getAlignment() && "Alignment must be set");
Attr = Attribute::getWithAlignment(C, *B.getAlignment());
Reland "[IR] Make AttributeSetNode public, avoid temporary AttributeList copies" This re-lands r299875. I introduced a bug in Clang code responsible for replacing K&R, no prototype declarations with a real function definition with a prototype. The bug was here: // Collect any return attributes from the call. - if (oldAttrs.hasAttributes(llvm::AttributeList::ReturnIndex)) - newAttrs.push_back(llvm::AttributeList::get(newFn->getContext(), - oldAttrs.getRetAttributes())); + newAttrs.push_back(oldAttrs.getRetAttributes()); Previously getRetAttributes() carried AttributeList::ReturnIndex in its AttributeList. Now that we return the AttributeSetNode* directly, it no longer carries that index, and we call this overload with a single node: AttributeList::get(LLVMContext&, ArrayRef<AttributeSetNode*>) That aborted with an assertion on x86_32 targets. I added an explicit triple to the test and added CHECKs to help find issues like this in the future sooner. llvm-svn: 299899
2017-04-11 07:31:05 +08:00
break;
case Attribute::StackAlignment:
[Alignment][NFC] Use MaybeAlign in AttrBuilder Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69300 llvm-svn: 375496
2019-10-22 19:57:52 +08:00
assert(B.getStackAlignment() && "StackAlignment must be set");
Attr = Attribute::getWithStackAlignment(C, *B.getStackAlignment());
Reland "[IR] Make AttributeSetNode public, avoid temporary AttributeList copies" This re-lands r299875. I introduced a bug in Clang code responsible for replacing K&R, no prototype declarations with a real function definition with a prototype. The bug was here: // Collect any return attributes from the call. - if (oldAttrs.hasAttributes(llvm::AttributeList::ReturnIndex)) - newAttrs.push_back(llvm::AttributeList::get(newFn->getContext(), - oldAttrs.getRetAttributes())); + newAttrs.push_back(oldAttrs.getRetAttributes()); Previously getRetAttributes() carried AttributeList::ReturnIndex in its AttributeList. Now that we return the AttributeSetNode* directly, it no longer carries that index, and we call this overload with a single node: AttributeList::get(LLVMContext&, ArrayRef<AttributeSetNode*>) That aborted with an assertion on x86_32 targets. I added an explicit triple to the test and added CHECKs to help find issues like this in the future sooner. llvm-svn: 299899
2017-04-11 07:31:05 +08:00
break;
case Attribute::Dereferenceable:
Attr = Attribute::getWithDereferenceableBytes(
C, B.getDereferenceableBytes());
break;
case Attribute::DereferenceableOrNull:
Attr = Attribute::getWithDereferenceableOrNullBytes(
C, B.getDereferenceableOrNullBytes());
break;
case Attribute::AllocSize: {
auto A = B.getAllocSizeArgs();
Attr = Attribute::getWithAllocSizeArgs(C, A.first, A.second);
break;
}
default:
Attr = Attribute::get(C, Kind);
}
Attrs.push_back(Attr);
}
// Add target-dependent (string) attributes.
for (const auto &TDA : B.td_attrs())
Attrs.emplace_back(Attribute::get(C, TDA.first, TDA.second));
Sort EnumAttr so it matches Attribute::operator< This means AttrBuilder will always create a sorted set of attributes and we can skip the sorting step. Sorting attributes is surprisingly expensive, and I recently made it worse by making it use array_pod_sort.
2020-04-26 22:52:53 +08:00
return getSorted(C, Attrs);
Reland "[IR] Make AttributeSetNode public, avoid temporary AttributeList copies" This re-lands r299875. I introduced a bug in Clang code responsible for replacing K&R, no prototype declarations with a real function definition with a prototype. The bug was here: // Collect any return attributes from the call. - if (oldAttrs.hasAttributes(llvm::AttributeList::ReturnIndex)) - newAttrs.push_back(llvm::AttributeList::get(newFn->getContext(), - oldAttrs.getRetAttributes())); + newAttrs.push_back(oldAttrs.getRetAttributes()); Previously getRetAttributes() carried AttributeList::ReturnIndex in its AttributeList. Now that we return the AttributeSetNode* directly, it no longer carries that index, and we call this overload with a single node: AttributeList::get(LLVMContext&, ArrayRef<AttributeSetNode*>) That aborted with an assertion on x86_32 targets. I added an explicit triple to the test and added CHECKs to help find issues like this in the future sooner. llvm-svn: 299899
2017-04-11 07:31:05 +08:00
}
Add some accessor and query methods for retrieving Attribute objects and such. llvm-svn: 175046
2013-02-13 16:42:21 +08:00
bool AttributeSetNode::hasAttribute(StringRef Kind) const {
[IR] Use map for string attributes (NFC) Attributes are currently stored as a simple list. Enum attributes additionally use a bitset to allow quickly determining whether an attribute is set. String attributes on the other hand require a full scan of the list. As functions tend to have a lot of string attributes (at least when clang is used), this is a noticeable performance issue. This patch adds an additional name => attribute map to the AttributeSetNode, which allows querying string attributes quickly. This results in a 3% reduction in instructions retired on CTMark. Changes to memory usage seem to be in the noise (attribute sets are uniqued, and we don't tend to have more than a few dozen or hundred unique attribute sets, so adding an extra map does not have a noticeable cost.) Differential Revision: https://reviews.llvm.org/D78859
2020-04-25 18:21:21 +08:00
return StringAttrs.count(Kind);
Add some accessor and query methods for retrieving Attribute objects and such. llvm-svn: 175046
2013-02-13 16:42:21 +08:00
}
[IR] Since AttributeSets are sorted, binary search them. Not likely to make a big difference, but there's a fair bit of pointer chasing in large sets.
2020-04-27 02:03:29 +08:00
Optional<Attribute>
AttributeSetNode::findEnumAttribute(Attribute::AttrKind Kind) const {
// Do a quick presence check.
if (!hasAttribute(Kind))
return None;
// Attributes in a set are sorted by enum value, followed by string
// attributes. Binary search the one we want.
const Attribute *I =
std::lower_bound(begin(), end() - StringAttrs.size(), Kind,
[](Attribute A, Attribute::AttrKind Kind) {
return A.getKindAsEnum() < Kind;
});
assert(I != end() && I->hasAttribute(Kind) && "Presence check failed?");
return *I;
}
Add some accessor and query methods for retrieving Attribute objects and such. llvm-svn: 175046
2013-02-13 16:42:21 +08:00
Attribute AttributeSetNode::getAttribute(Attribute::AttrKind Kind) const {
[IR] Since AttributeSets are sorted, binary search them. Not likely to make a big difference, but there's a fair bit of pointer chasing in large sets.
2020-04-27 02:03:29 +08:00
if (auto A = findEnumAttribute(Kind))
return *A;
[IR] Fix some Clang-tidy modernize-use-auto warnings; other minor fixes (NFC). llvm-svn: 328850
2018-03-30 08:47:31 +08:00
return {};
Add some accessor and query methods for retrieving Attribute objects and such. llvm-svn: 175046
2013-02-13 16:42:21 +08:00
}
Attribute AttributeSetNode::getAttribute(StringRef Kind) const {
[IR] Use map for string attributes (NFC) Attributes are currently stored as a simple list. Enum attributes additionally use a bitset to allow quickly determining whether an attribute is set. String attributes on the other hand require a full scan of the list. As functions tend to have a lot of string attributes (at least when clang is used), this is a noticeable performance issue. This patch adds an additional name => attribute map to the AttributeSetNode, which allows querying string attributes quickly. This results in a 3% reduction in instructions retired on CTMark. Changes to memory usage seem to be in the noise (attribute sets are uniqued, and we don't tend to have more than a few dozen or hundred unique attribute sets, so adding an extra map does not have a noticeable cost.) Differential Revision: https://reviews.llvm.org/D78859
2020-04-25 18:21:21 +08:00
return StringAttrs.lookup(Kind);
Add some accessor and query methods for retrieving Attribute objects and such. llvm-svn: 175046
2013-02-13 16:42:21 +08:00
}
[Alignment][NFC] Attributes use Align/MaybeAlign Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Subscribers: jholewinski, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69278 llvm-svn: 375495
2019-10-22 17:51:06 +08:00
MaybeAlign AttributeSetNode::getAlignment() const {
[IR] Since AttributeSets are sorted, binary search them. Not likely to make a big difference, but there's a fair bit of pointer chasing in large sets.
2020-04-27 02:03:29 +08:00
if (auto A = findEnumAttribute(Attribute::Alignment))
return A->getAlignment();
[Alignment][NFC] Attributes use Align/MaybeAlign Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Subscribers: jholewinski, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69278 llvm-svn: 375495
2019-10-22 17:51:06 +08:00
return None;
Convert getAttributes() to return an AttributeSetNode. The AttributeSetNode contains all of the attributes. This removes one (hopefully last) use of the Attribute class as a container of multiple attributes. llvm-svn: 173761
2013-01-29 11:20:31 +08:00
}
[Alignment][NFC] Attributes use Align/MaybeAlign Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Subscribers: jholewinski, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69278 llvm-svn: 375495
2019-10-22 17:51:06 +08:00
MaybeAlign AttributeSetNode::getStackAlignment() const {
[IR] Since AttributeSets are sorted, binary search them. Not likely to make a big difference, but there's a fair bit of pointer chasing in large sets.
2020-04-27 02:03:29 +08:00
if (auto A = findEnumAttribute(Attribute::StackAlignment))
return A->getStackAlignment();
[Alignment][NFC] Attributes use Align/MaybeAlign Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Subscribers: jholewinski, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69278 llvm-svn: 375495
2019-10-22 17:51:06 +08:00
return None;
Convert getAttributes() to return an AttributeSetNode. The AttributeSetNode contains all of the attributes. This removes one (hopefully last) use of the Attribute class as a container of multiple attributes. llvm-svn: 173761
2013-01-29 11:20:31 +08:00
}
Reapply: IR: add optional type to 'byval' function parameters When we switch to opaque pointer types we will need some way to describe how many bytes a 'byval' parameter should occupy on the stack. This adds a (for now) optional extra type parameter. If present, the type must match the pointee type of the argument. The original commit did not remap byval types when linking modules, which broke LTO. This version fixes that. Note to front-end maintainers: if this causes test failures, it's probably because the "byval" attribute is printed after attributes without any parameter after this change. llvm-svn: 362128
2019-05-31 02:48:23 +08:00
Type *AttributeSetNode::getByValType() const {
[IR] Since AttributeSets are sorted, binary search them. Not likely to make a big difference, but there's a fair bit of pointer chasing in large sets.
2020-04-27 02:03:29 +08:00
if (auto A = findEnumAttribute(Attribute::ByVal))
return A->getValueAsType();
Use findEnumAttribute helper for preallocated
2020-07-10 09:02:25 +08:00
return nullptr;
Reapply: IR: add optional type to 'byval' function parameters When we switch to opaque pointer types we will need some way to describe how many bytes a 'byval' parameter should occupy on the stack. This adds a (for now) optional extra type parameter. If present, the type must match the pointee type of the argument. The original commit did not remap byval types when linking modules, which broke LTO. This version fixes that. Note to front-end maintainers: if this causes test failures, it's probably because the "byval" attribute is printed after attributes without any parameter after this change. llvm-svn: 362128
2019-05-31 02:48:23 +08:00
}
Reapply "OpaquePtr: Add type to sret attribute" This reverts commit eb9f7c28e5fe6d75fed3587023e17f2997c8024b. Previously this was incorrectly handling linking of the contained type, so this merges the fixes from D88973.
2020-09-29 21:33:55 +08:00
Type *AttributeSetNode::getStructRetType() const {
if (auto A = findEnumAttribute(Attribute::StructRet))
return A->getValueAsType();
return nullptr;
}
IR: Define byref parameter attribute This allows tracking the in-memory type of a pointer argument to a function for ABI purposes. This is essentially a stripped down version of byval to remove some of the stack-copy implications in its definition. This includes the base IR changes, and some tests for places where it should be treated similarly to byval. Codegen support will be in a future patch. My original attempt at solving some of these problems was to repurpose byval with a different address space from the stack. However, it is technically permitted for the callee to introduce a write to the argument, although nothing does this in reality. There is also talk of removing and replacing the byval attribute, so a new attribute would need to take its place anyway. This is intended avoid some optimization issues with the current handling of aggregate arguments, as well as fixes inflexibilty in how frontends can specify the kernel ABI. The most honest representation of the amdgpu_kernel convention is to expose all kernel arguments as loads from constant memory. Today, these are raw, SSA Argument values and codegen is responsible for turning these into loads. Background: There currently isn't a satisfactory way to represent how arguments for the amdgpu_kernel calling convention are passed. In reality, arguments are passed in a single, flat, constant memory buffer implicitly passed to the function. It is also illegal to call this function in the IR, and this is only ever invoked by a driver of some kind. It does not make sense to have a stack passed parameter in this context as is implied by byval. It is never valid to write to the kernel arguments, as this would corrupt the inputs seen by other dispatches of the kernel. These argumets are also not in the same address space as the stack, so a copy is needed to an alloca. From a source C-like language, the kernel parameters are invisible. Semantically, a copy is always required from the constant argument memory to a mutable variable. The current clang calling convention lowering emits raw values, including aggregates into the function argument list, since using byval would not make sense. This has some unfortunate consequences for the optimizer. In the aggregate case, we end up with an aggregate store to alloca, which both SROA and instcombine turn into a store of each aggregate field. The optimizer never pieces this back together to see that this is really just a copy from constant memory, so we end up stuck with expensive stack usage. This also means the backend dictates the alignment of arguments, and arbitrarily picks the LLVM IR ABI type alignment. By allowing an explicit alignment, frontends can make better decisions. For example, there's real no advantage to an aligment higher than 4, so a frontend could choose to compact the argument layout. Similarly, there is a high penalty to using an alignment lower than 4, so a frontend could opt into more padding for small arguments. Another design consideration is when it is appropriate to expose the fact that these arguments are all really passed in adjacent memory. Currently we have a late IR optimization pass in codegen to rewrite the kernel argument values into explicit loads to enable vectorization. In most programs, unrelated argument loads can be merged together. However, exposing this property directly from the frontend has some disadvantages. We still need a way to track the original argument sizes and alignments to report to the driver. I find using some side-channel, metadata mechanism to track this unappealing. If the kernel arguments were exposed as a single buffer to begin with, alias analysis would be unaware that the padding bits betewen arguments are meaningless. Another family of problems is there are still some gaps in replacing all of the available parameter attributes with metadata equivalents once lowered to loads. The immediate plan is to start using this new attribute to handle all aggregate argumets for kernels. Long term, it makes sense to migrate all kernel arguments, including scalars, to be passed indirectly in the same manner. Additional context is in D79744.
2020-06-06 04:58:47 +08:00
Type *AttributeSetNode::getByRefType() const {
if (auto A = findEnumAttribute(Attribute::ByRef))
return A->getValueAsType();
return nullptr;
}
Add IR constructs for preallocated (inalloca replacement) Add llvm.call.preallocated.{setup,arg} instrinsics. Add "preallocated" operand bundle which takes a token produced by llvm.call.preallocated.setup. Add "preallocated" parameter attribute, which is like byval but without the copy. Verifier changes for these IR constructs. See https://github.com/rnk/llvm-project/blob/call-setup-docs/llvm/docs/CallSetup.md Subscribers: hiraditya, jdoerfert, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D74651
2020-02-15 06:16:53 +08:00
Type *AttributeSetNode::getPreallocatedType() const {
Use findEnumAttribute helper for preallocated
2020-07-10 09:02:25 +08:00
if (auto A = findEnumAttribute(Attribute::Preallocated))
return A->getValueAsType();
return nullptr;
Add IR constructs for preallocated (inalloca replacement) Add llvm.call.preallocated.{setup,arg} instrinsics. Add "preallocated" operand bundle which takes a token produced by llvm.call.preallocated.setup. Add "preallocated" parameter attribute, which is like byval but without the copy. Verifier changes for these IR constructs. See https://github.com/rnk/llvm-project/blob/call-setup-docs/llvm/docs/CallSetup.md Subscribers: hiraditya, jdoerfert, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D74651
2020-02-15 06:16:53 +08:00
}
Add a dereferenceable attribute This attribute indicates that the parameter or return pointer is dereferenceable. Practically speaking, loads from such a pointer within the associated byte range are safe to speculatively execute. Such pointer parameters are common in source languages (C++ references, for example). llvm-svn: 213385
2014-07-18 23:51:28 +08:00
uint64_t AttributeSetNode::getDereferenceableBytes() const {
[IR] Since AttributeSets are sorted, binary search them. Not likely to make a big difference, but there's a fair bit of pointer chasing in large sets.
2020-04-27 02:03:29 +08:00
if (auto A = findEnumAttribute(Attribute::Dereferenceable))
return A->getDereferenceableBytes();
Add a dereferenceable attribute This attribute indicates that the parameter or return pointer is dereferenceable. Practically speaking, loads from such a pointer within the associated byte range are safe to speculatively execute. Such pointer parameters are common in source languages (C++ references, for example). llvm-svn: 213385
2014-07-18 23:51:28 +08:00
return 0;
}
Add missing dereferenceable_or_null getters Summary: Add missing dereferenceable_or_null getters required for http://reviews.llvm.org/D9253 change. Separated from the D9253 review. Patch by Artur Pilipenko! Reviewers: sanjoy Reviewed By: sanjoy Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D9499 llvm-svn: 236615
2015-05-07 01:41:54 +08:00
uint64_t AttributeSetNode::getDereferenceableOrNullBytes() const {
[IR] Since AttributeSets are sorted, binary search them. Not likely to make a big difference, but there's a fair bit of pointer chasing in large sets.
2020-04-27 02:03:29 +08:00
if (auto A = findEnumAttribute(Attribute::DereferenceableOrNull))
return A->getDereferenceableOrNullBytes();
Add missing dereferenceable_or_null getters Summary: Add missing dereferenceable_or_null getters required for http://reviews.llvm.org/D9253 change. Separated from the D9253 review. Patch by Artur Pilipenko! Reviewers: sanjoy Reviewed By: sanjoy Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D9499 llvm-svn: 236615
2015-05-07 01:41:54 +08:00
return 0;
}
Add the allocsize attribute to LLVM. `allocsize` is a function attribute that allows users to request that LLVM treat arbitrary functions as allocation functions. This patch makes LLVM accept the `allocsize` attribute, and makes `@llvm.objectsize` recognize said attribute. The review for this was split into two patches for ease of reviewing: D18974 and D14933. As promised on the revisions, I'm landing both patches as a single commit. Differential Revision: http://reviews.llvm.org/D14933 llvm-svn: 266032
2016-04-12 09:05:35 +08:00
std::pair<unsigned, Optional<unsigned>>
AttributeSetNode::getAllocSizeArgs() const {
[IR] Since AttributeSets are sorted, binary search them. Not likely to make a big difference, but there's a fair bit of pointer chasing in large sets.
2020-04-27 02:03:29 +08:00
if (auto A = findEnumAttribute(Attribute::AllocSize))
return A->getAllocSizeArgs();
Add the allocsize attribute to LLVM. `allocsize` is a function attribute that allows users to request that LLVM treat arbitrary functions as allocation functions. This patch makes LLVM accept the `allocsize` attribute, and makes `@llvm.objectsize` recognize said attribute. The review for this was split into two patches for ease of reviewing: D18974 and D14933. As promised on the revisions, I'm landing both patches as a single commit. Differential Revision: http://reviews.llvm.org/D14933 llvm-svn: 266032
2016-04-12 09:05:35 +08:00
return std::make_pair(0, 0);
}
Now that the underlying issue is fixed, revert r180750 and r180722. The cause of the windows failures was fixed by r180791. Revert to the state after Sabre's original revert. Original message: revert r179735, it has no testcases, and doesn't really make sense. llvm-svn: 180844
2013-05-01 21:07:03 +08:00
std::string AttributeSetNode::getAsString(bool InAttrGrp) const {
Attributes: Don't print trailing whitespace on the function attribute comment. llvm-svn: 179849
2013-04-19 19:43:21 +08:00
std::string Str;
Reduce the number of indirections in the attributes implementation. - Coallocate entires for AttributeSetImpls and Nodes after the class itself. - Remove mutable iterators from immutable classes. - Remove unused context field from AttributeImpl. - Derive Enum/Align/String attribute implementations from AttributeImpl instead of having a whole new inheritance tree for them. - Derive AlignAttributeImpl from EnumAttributeImpl. llvm-svn: 186075
2013-07-11 20:13:16 +08:00
for (iterator I = begin(), E = end(); I != E; ++I) {
if (I != begin())
Now that the underlying issue is fixed, revert r180750 and r180722. The cause of the windows failures was fixed by r180791. Revert to the state after Sabre's original revert. Original message: revert r179735, it has no testcases, and doesn't really make sense. llvm-svn: 180844
2013-05-01 21:07:03 +08:00
Str += ' ';
Str += I->getAsString(InAttrGrp);
Convert getAttributes() to return an AttributeSetNode. The AttributeSetNode contains all of the attributes. This removes one (hopefully last) use of the Attribute class as a container of multiple attributes. llvm-svn: 173761
2013-01-29 11:20:31 +08:00
}
return Str;
}
Reimplement the parameter attributes support, phase #1. hilights: 1. There is now a "PAListPtr" class, which is a smart pointer around the underlying uniqued parameter attribute list object, and manages its refcount. It is now impossible to mess up the refcount. 2. PAListPtr is now the main interface to the underlying object, and the underlying object is now completely opaque. 3. Implementation details like SmallVector and FoldingSet are now no longer part of the interface. 4. You can create a PAListPtr with an arbitrary sequence of ParamAttrsWithIndex's, no need to make a SmallVector of a specific size (you can just use an array or scalar or vector if you wish). 5. All the client code that had to check for a null pointer before dereferencing the pointer is simplified to just access the PAListPtr directly. 6. The interfaces for adding attrs to a list and removing them is a bit simpler. Phase #2 will rename some stuff (e.g. PAListPtr) and do other less invasive changes. llvm-svn: 48289
2008-03-13 01:45:29 +08:00
//===----------------------------------------------------------------------===//
Rename AttributeSet to AttributeList Summary: This class is a list of AttributeSetNodes corresponding the function prototype of a call or function declaration. This class used to be called ParamAttrListPtr, then AttrListPtr, then AttributeSet. It is typically accessed by parameter and return value index, so "AttributeList" seems like a more intuitive name. Rename AttributeSetImpl to AttributeListImpl to follow suit. It's useful to rename this class so that we can rename AttributeSetNode to AttributeSet later. AttributeSet is the set of attributes that apply to a single function, argument, or return value. Reviewers: sanjoy, javed.absar, chandlerc, pete Reviewed By: pete Subscribers: pete, jholewinski, arsenm, dschuff, mehdi_amini, jfb, nhaehnle, sbc100, void, llvm-commits Differential Revision: https://reviews.llvm.org/D31102 llvm-svn: 298393
2017-03-22 00:57:19 +08:00
// AttributeListImpl Definition
Reimplement the parameter attributes support, phase #1. hilights: 1. There is now a "PAListPtr" class, which is a smart pointer around the underlying uniqued parameter attribute list object, and manages its refcount. It is now impossible to mess up the refcount. 2. PAListPtr is now the main interface to the underlying object, and the underlying object is now completely opaque. 3. Implementation details like SmallVector and FoldingSet are now no longer part of the interface. 4. You can create a PAListPtr with an arbitrary sequence of ParamAttrsWithIndex's, no need to make a SmallVector of a specific size (you can just use an array or scalar or vector if you wish). 5. All the client code that had to check for a null pointer before dereferencing the pointer is simplified to just access the PAListPtr directly. 6. The interfaces for adding attrs to a list and removing them is a bit simpler. Phase #2 will rename some stuff (e.g. PAListPtr) and do other less invasive changes. llvm-svn: 48289
2008-03-13 01:45:29 +08:00
//===----------------------------------------------------------------------===//
Silence MSVC warnings about unsigned wrapping without UB Of course, casting an unsigned value too large for 'int' is UB. So, write out the ternary. LLVM folds it to ADD anyway. Fixes the warning from r303693 a different way. Thanks to Erich Keane for pointing this out! llvm-svn: 315406
2017-10-11 09:40:38 +08:00
/// Map from AttributeList index to the internal array index. Adding one happens
[IR] Remove MSVC warning workaround (NFC) While LLVM does fold this to x+1, GCC does not. As this is hot code, let's try to avoid that. According to https://developercommunity.visualstudio.com/content/problem/211134/unsigned-integer-overflows-in-constexpr-functionsa.html this spurious warning in MSVC has been fixed in Visual Studio 2019 Version 16.4. Let's see if there are any build bots running old MSVC versions with warnings treated as errors...
2020-06-24 04:25:04 +08:00
/// to work, because -1 wraps around to 0.
[IR] Fix MSVC warning (NFC) As requested by Andrew Kaylor, rewrite this code in a way that does not warn on old MSVC versions. Avoid the buggy constexpr warning by just not using constexpr and removing the static_assert that depends on it.
2020-07-18 00:25:56 +08:00
static unsigned attrIdxToArrayIdx(unsigned Index) {
[IR] Remove MSVC warning workaround (NFC) While LLVM does fold this to x+1, GCC does not. As this is hot code, let's try to avoid that. According to https://developercommunity.visualstudio.com/content/problem/211134/unsigned-integer-overflows-in-constexpr-functionsa.html this spurious warning in MSVC has been fixed in Visual Studio 2019 Version 16.4. Let's see if there are any build bots running old MSVC versions with warnings treated as errors...
2020-06-24 04:25:04 +08:00
return Index + 1;
[IR] Switch AttributeList to use an array for O(1) access Summary: Before this change, AttributeLists stored a pair of index and AttributeSet. This is memory efficient if most arguments do not have attributes. However, it requires doing a search over the pairs to test an argument or function attribute. Profiling shows that this loop was 0.76% of the time in 'opt -O2' of sqlite3.c, because LLVM constantly tests values for nullability. This was worth about 2.5% of mid-level optimization cycles on the sqlite3 amalgamation. Here are the full perf results: https://reviews.llvm.org/P7995 Here are just the before and after cycle counts: ``` $ perf stat -r 5 ./opt_before -O2 sqlite3.bc -o /dev/null 13,274,181,184 cycles # 3.047 GHz ( +- 0.28% ) $ perf stat -r 5 ./opt_after -O2 sqlite3.bc -o /dev/null 12,906,927,263 cycles # 3.043 GHz ( +- 0.51% ) ``` This patch *does not* change the indices used to query attributes, as requested by reviewers. Tracking whether an index is usable for array indexing is a huge pain that affects many of the internal APIs, so it would be good to come back later and do a cleanup to remove this internal adjustment. Reviewers: pete, chandlerc Subscribers: javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D32819 llvm-svn: 303654
2017-05-24 01:01:48 +08:00
}
[IR] AttributeList::getContext has a single user, remove it.
2020-05-01 20:18:29 +08:00
AttributeListImpl::AttributeListImpl(ArrayRef<AttributeSet> Sets)
: NumAttrSets(Sets.size()) {
[IR] Switch AttributeList to use an array for O(1) access Summary: Before this change, AttributeLists stored a pair of index and AttributeSet. This is memory efficient if most arguments do not have attributes. However, it requires doing a search over the pairs to test an argument or function attribute. Profiling shows that this loop was 0.76% of the time in 'opt -O2' of sqlite3.c, because LLVM constantly tests values for nullability. This was worth about 2.5% of mid-level optimization cycles on the sqlite3 amalgamation. Here are the full perf results: https://reviews.llvm.org/P7995 Here are just the before and after cycle counts: ``` $ perf stat -r 5 ./opt_before -O2 sqlite3.bc -o /dev/null 13,274,181,184 cycles # 3.047 GHz ( +- 0.28% ) $ perf stat -r 5 ./opt_after -O2 sqlite3.bc -o /dev/null 12,906,927,263 cycles # 3.043 GHz ( +- 0.51% ) ``` This patch *does not* change the indices used to query attributes, as requested by reviewers. Tracking whether an index is usable for array indexing is a huge pain that affects many of the internal APIs, so it would be good to come back later and do a cleanup to remove this internal adjustment. Reviewers: pete, chandlerc Subscribers: javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D32819 llvm-svn: 303654
2017-05-24 01:01:48 +08:00
assert(!Sets.empty() && "pointless AttributeListImpl");
[IR] Sink some AttributeListImpl methods out of headers NFC llvm-svn: 299906
2017-04-11 08:16:00 +08:00
// There's memory after the node where we can store the entries in.
Use llvm::copy. NFC llvm-svn: 347126
2018-11-17 09:44:25 +08:00
llvm::copy(Sets, getTrailingObjects<AttributeSet>());
[IR] Sink some AttributeListImpl methods out of headers NFC llvm-svn: 299906
2017-04-11 08:16:00 +08:00
[IR] Store attributes that are available "somewhere" (NFC) I noticed that for some benchmarks we spend quite a bit of time inside AttributeList::hasAttrSomewhere(), mainly when checking for the "returned" attribute. Most of the time the attribute will not be present, in which case this function has to walk through the whole attribute list and check for the attribute at each index. This patch adds a cache of all "available somewhere" attributes inside AttributeListImpl. This makes the structure 12 bytes larger, but I don't think that's problematic, as attribute lists are uniqued. Compile-time in terms of instructions retired improves by 0.4% on average, but >1% for sqlite. Differential Revision: https://reviews.llvm.org/D81867
2020-06-15 04:49:57 +08:00
// Initialize AvailableFunctionAttrs and AvailableSomewhereAttrs
// summary bitsets.
[IR] Fix MSVC warning (NFC) As requested by Andrew Kaylor, rewrite this code in a way that does not warn on old MSVC versions. Avoid the buggy constexpr warning by just not using constexpr and removing the static_assert that depends on it.
2020-07-18 00:25:56 +08:00
for (const auto &I : Sets[attrIdxToArrayIdx(AttributeList::FunctionIndex)])
[IR] Add AttributeBitSet wrapper (NFC) This wraps the uint8_t[12] type used in two places, because I plan to introduce a third use of the same pattern.
2020-06-15 05:46:18 +08:00
if (!I.isStringAttribute())
AvailableFunctionAttrs.addAttribute(I.getKindAsEnum());
[IR] Store attributes that are available "somewhere" (NFC) I noticed that for some benchmarks we spend quite a bit of time inside AttributeList::hasAttrSomewhere(), mainly when checking for the "returned" attribute. Most of the time the attribute will not be present, in which case this function has to walk through the whole attribute list and check for the attribute at each index. This patch adds a cache of all "available somewhere" attributes inside AttributeListImpl. This makes the structure 12 bytes larger, but I don't think that's problematic, as attribute lists are uniqued. Compile-time in terms of instructions retired improves by 0.4% on average, but >1% for sqlite. Differential Revision: https://reviews.llvm.org/D81867
2020-06-15 04:49:57 +08:00
for (const auto &Set : Sets)
for (const auto &I : Set)
if (!I.isStringAttribute())
AvailableSomewhereAttrs.addAttribute(I.getKindAsEnum());
[IR] Sink some AttributeListImpl methods out of headers NFC llvm-svn: 299906
2017-04-11 08:16:00 +08:00
}
void AttributeListImpl::Profile(FoldingSetNodeID &ID) const {
[IR] Switch AttributeList to use an array for O(1) access Summary: Before this change, AttributeLists stored a pair of index and AttributeSet. This is memory efficient if most arguments do not have attributes. However, it requires doing a search over the pairs to test an argument or function attribute. Profiling shows that this loop was 0.76% of the time in 'opt -O2' of sqlite3.c, because LLVM constantly tests values for nullability. This was worth about 2.5% of mid-level optimization cycles on the sqlite3 amalgamation. Here are the full perf results: https://reviews.llvm.org/P7995 Here are just the before and after cycle counts: ``` $ perf stat -r 5 ./opt_before -O2 sqlite3.bc -o /dev/null 13,274,181,184 cycles # 3.047 GHz ( +- 0.28% ) $ perf stat -r 5 ./opt_after -O2 sqlite3.bc -o /dev/null 12,906,927,263 cycles # 3.043 GHz ( +- 0.51% ) ``` This patch *does not* change the indices used to query attributes, as requested by reviewers. Tracking whether an index is usable for array indexing is a huge pain that affects many of the internal APIs, so it would be good to come back later and do a cleanup to remove this internal adjustment. Reviewers: pete, chandlerc Subscribers: javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D32819 llvm-svn: 303654
2017-05-24 01:01:48 +08:00
Profile(ID, makeArrayRef(begin(), end()));
[IR] Sink some AttributeListImpl methods out of headers NFC llvm-svn: 299906
2017-04-11 08:16:00 +08:00
}
[IR] Switch AttributeList to use an array for O(1) access Summary: Before this change, AttributeLists stored a pair of index and AttributeSet. This is memory efficient if most arguments do not have attributes. However, it requires doing a search over the pairs to test an argument or function attribute. Profiling shows that this loop was 0.76% of the time in 'opt -O2' of sqlite3.c, because LLVM constantly tests values for nullability. This was worth about 2.5% of mid-level optimization cycles on the sqlite3 amalgamation. Here are the full perf results: https://reviews.llvm.org/P7995 Here are just the before and after cycle counts: ``` $ perf stat -r 5 ./opt_before -O2 sqlite3.bc -o /dev/null 13,274,181,184 cycles # 3.047 GHz ( +- 0.28% ) $ perf stat -r 5 ./opt_after -O2 sqlite3.bc -o /dev/null 12,906,927,263 cycles # 3.043 GHz ( +- 0.51% ) ``` This patch *does not* change the indices used to query attributes, as requested by reviewers. Tracking whether an index is usable for array indexing is a huge pain that affects many of the internal APIs, so it would be good to come back later and do a cleanup to remove this internal adjustment. Reviewers: pete, chandlerc Subscribers: javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D32819 llvm-svn: 303654
2017-05-24 01:01:48 +08:00
void AttributeListImpl::Profile(FoldingSetNodeID &ID,
ArrayRef<AttributeSet> Sets) {
for (const auto &Set : Sets)
ID.AddPointer(Set.SetNode);
[IR] Sink some AttributeListImpl methods out of headers NFC llvm-svn: 299906
2017-04-11 08:16:00 +08:00
}
[IR] Store attributes that are available "somewhere" (NFC) I noticed that for some benchmarks we spend quite a bit of time inside AttributeList::hasAttrSomewhere(), mainly when checking for the "returned" attribute. Most of the time the attribute will not be present, in which case this function has to walk through the whole attribute list and check for the attribute at each index. This patch adds a cache of all "available somewhere" attributes inside AttributeListImpl. This makes the structure 12 bytes larger, but I don't think that's problematic, as attribute lists are uniqued. Compile-time in terms of instructions retired improves by 0.4% on average, but >1% for sqlite. Differential Revision: https://reviews.llvm.org/D81867
2020-06-15 04:49:57 +08:00
bool AttributeListImpl::hasAttrSomewhere(Attribute::AttrKind Kind,
unsigned *Index) const {
if (!AvailableSomewhereAttrs.hasAttribute(Kind))
return false;
if (Index) {
for (unsigned I = 0, E = NumAttrSets; I != E; ++I) {
if (begin()[I].hasAttribute(Kind)) {
*Index = I - 1;
break;
}
}
}
return true;
}
Reverting r315590; it did not include changes for llvm-tblgen, which is causing link errors for several people. Error LNK2019 unresolved external symbol "public: void __cdecl `anonymous namespace'::MatchableInfo::dump(void)const " (?dump@MatchableInfo@?A0xf4f1c304@@QEBAXXZ) referenced in function "public: void __cdecl `anonymous namespace'::AsmMatcherEmitter::run(class llvm::raw_ostream &)" (?run@AsmMatcherEmitter@?A0xf4f1c304@@QEAAXAEAVraw_ostream@llvm@@@Z) llvm-tblgen D:\llvm\2017\utils\TableGen\AsmMatcherEmitter.obj 1 llvm-svn: 315854
2017-10-15 22:32:27 +08:00
#if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP)
Rename AttributeSet to AttributeList Summary: This class is a list of AttributeSetNodes corresponding the function prototype of a call or function declaration. This class used to be called ParamAttrListPtr, then AttrListPtr, then AttributeSet. It is typically accessed by parameter and return value index, so "AttributeList" seems like a more intuitive name. Rename AttributeSetImpl to AttributeListImpl to follow suit. It's useful to rename this class so that we can rename AttributeSetNode to AttributeSet later. AttributeSet is the set of attributes that apply to a single function, argument, or return value. Reviewers: sanjoy, javed.absar, chandlerc, pete Reviewed By: pete Subscribers: pete, jholewinski, arsenm, dschuff, mehdi_amini, jfb, nhaehnle, sbc100, void, llvm-commits Differential Revision: https://reviews.llvm.org/D31102 llvm-svn: 298393
2017-03-22 00:57:19 +08:00
LLVM_DUMP_METHOD void AttributeListImpl::dump() const {
AttributeList(const_cast<AttributeListImpl *>(this)).dump();
Add a AttributeSetImpl::dump function. This is for the benefit of those of us with inferior debuggers which do not permit member function calls on value types. llvm-svn: 187685
2013-08-03 06:34:30 +08:00
}
Cleanup dump() functions. We had various variants of defining dump() functions in LLVM. Normalize them (this should just consistently implement the things discussed in http://lists.llvm.org/pipermail/cfe-dev/2014-January/034323.html For reference: - Public headers should just declare the dump() method but not use LLVM_DUMP_METHOD or #if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP) - The definition of a dump method should look like this: #if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP) LLVM_DUMP_METHOD void MyClass::dump() { // print stuff to dbgs()... } #endif llvm-svn: 293359
2017-01-28 10:02:38 +08:00
#endif
Add a AttributeSetImpl::dump function. This is for the benefit of those of us with inferior debuggers which do not permit member function calls on value types. llvm-svn: 187685
2013-08-03 06:34:30 +08:00
In the AttributeSetImpl c'tor, fill in the AttrNodes data structure with the attributes being passed in. llvm-svn: 173618
2013-01-27 20:50:02 +08:00
//===----------------------------------------------------------------------===//
Rename AttributeSet to AttributeList Summary: This class is a list of AttributeSetNodes corresponding the function prototype of a call or function declaration. This class used to be called ParamAttrListPtr, then AttrListPtr, then AttributeSet. It is typically accessed by parameter and return value index, so "AttributeList" seems like a more intuitive name. Rename AttributeSetImpl to AttributeListImpl to follow suit. It's useful to rename this class so that we can rename AttributeSetNode to AttributeSet later. AttributeSet is the set of attributes that apply to a single function, argument, or return value. Reviewers: sanjoy, javed.absar, chandlerc, pete Reviewed By: pete Subscribers: pete, jholewinski, arsenm, dschuff, mehdi_amini, jfb, nhaehnle, sbc100, void, llvm-commits Differential Revision: https://reviews.llvm.org/D31102 llvm-svn: 298393
2017-03-22 00:57:19 +08:00
// AttributeList Construction and Mutation Methods
In the AttributeSetImpl c'tor, fill in the AttrNodes data structure with the attributes being passed in. llvm-svn: 173618
2013-01-27 20:50:02 +08:00
//===----------------------------------------------------------------------===//
[IR] Switch AttributeList to use an array for O(1) access Summary: Before this change, AttributeLists stored a pair of index and AttributeSet. This is memory efficient if most arguments do not have attributes. However, it requires doing a search over the pairs to test an argument or function attribute. Profiling shows that this loop was 0.76% of the time in 'opt -O2' of sqlite3.c, because LLVM constantly tests values for nullability. This was worth about 2.5% of mid-level optimization cycles on the sqlite3 amalgamation. Here are the full perf results: https://reviews.llvm.org/P7995 Here are just the before and after cycle counts: ``` $ perf stat -r 5 ./opt_before -O2 sqlite3.bc -o /dev/null 13,274,181,184 cycles # 3.047 GHz ( +- 0.28% ) $ perf stat -r 5 ./opt_after -O2 sqlite3.bc -o /dev/null 12,906,927,263 cycles # 3.043 GHz ( +- 0.51% ) ``` This patch *does not* change the indices used to query attributes, as requested by reviewers. Tracking whether an index is usable for array indexing is a huge pain that affects many of the internal APIs, so it would be good to come back later and do a cleanup to remove this internal adjustment. Reviewers: pete, chandlerc Subscribers: javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D32819 llvm-svn: 303654
2017-05-24 01:01:48 +08:00
AttributeList AttributeList::getImpl(LLVMContext &C,
ArrayRef<AttributeSet> AttrSets) {
assert(!AttrSets.empty() && "pointless AttributeListImpl");
Reland "[IR] Make AttributeSetNode public, avoid temporary AttributeList copies" This re-lands r299875. I introduced a bug in Clang code responsible for replacing K&R, no prototype declarations with a real function definition with a prototype. The bug was here: // Collect any return attributes from the call. - if (oldAttrs.hasAttributes(llvm::AttributeList::ReturnIndex)) - newAttrs.push_back(llvm::AttributeList::get(newFn->getContext(), - oldAttrs.getRetAttributes())); + newAttrs.push_back(oldAttrs.getRetAttributes()); Previously getRetAttributes() carried AttributeList::ReturnIndex in its AttributeList. Now that we return the AttributeSetNode* directly, it no longer carries that index, and we call this overload with a single node: AttributeList::get(LLVMContext&, ArrayRef<AttributeSetNode*>) That aborted with an assertion on x86_32 targets. I added an explicit triple to the test and added CHECKs to help find issues like this in the future sooner. llvm-svn: 299899
2017-04-11 07:31:05 +08:00
Reorder some functions and add comments. No functionality change. llvm-svn: 173733
2013-01-29 08:34:06 +08:00
LLVMContextImpl *pImpl = C.pImpl;
FoldingSetNodeID ID;
[IR] Switch AttributeList to use an array for O(1) access Summary: Before this change, AttributeLists stored a pair of index and AttributeSet. This is memory efficient if most arguments do not have attributes. However, it requires doing a search over the pairs to test an argument or function attribute. Profiling shows that this loop was 0.76% of the time in 'opt -O2' of sqlite3.c, because LLVM constantly tests values for nullability. This was worth about 2.5% of mid-level optimization cycles on the sqlite3 amalgamation. Here are the full perf results: https://reviews.llvm.org/P7995 Here are just the before and after cycle counts: ``` $ perf stat -r 5 ./opt_before -O2 sqlite3.bc -o /dev/null 13,274,181,184 cycles # 3.047 GHz ( +- 0.28% ) $ perf stat -r 5 ./opt_after -O2 sqlite3.bc -o /dev/null 12,906,927,263 cycles # 3.043 GHz ( +- 0.51% ) ``` This patch *does not* change the indices used to query attributes, as requested by reviewers. Tracking whether an index is usable for array indexing is a huge pain that affects many of the internal APIs, so it would be good to come back later and do a cleanup to remove this internal adjustment. Reviewers: pete, chandlerc Subscribers: javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D32819 llvm-svn: 303654
2017-05-24 01:01:48 +08:00
AttributeListImpl::Profile(ID, AttrSets);
Cleanup whitespace. llvm-svn: 166013
2012-10-16 14:01:44 +08:00
Make the AttrListPtr object a part of the LLVMContext. When code deletes the context, the AttributeImpls that the AttrListPtr points to are now invalid. Therefore, instead of keeping a separate managed static for the AttrListPtrs that's reference counted, move it into the LLVMContext and delete it when deleting the AttributeImpls. llvm-svn: 168354
2012-11-20 13:09:20 +08:00
void *InsertPoint;
Rename AttributeSet to AttributeList Summary: This class is a list of AttributeSetNodes corresponding the function prototype of a call or function declaration. This class used to be called ParamAttrListPtr, then AttrListPtr, then AttributeSet. It is typically accessed by parameter and return value index, so "AttributeList" seems like a more intuitive name. Rename AttributeSetImpl to AttributeListImpl to follow suit. It's useful to rename this class so that we can rename AttributeSetNode to AttributeSet later. AttributeSet is the set of attributes that apply to a single function, argument, or return value. Reviewers: sanjoy, javed.absar, chandlerc, pete Reviewed By: pete Subscribers: pete, jholewinski, arsenm, dschuff, mehdi_amini, jfb, nhaehnle, sbc100, void, llvm-commits Differential Revision: https://reviews.llvm.org/D31102 llvm-svn: 298393
2017-03-22 00:57:19 +08:00
AttributeListImpl *PA =
pImpl->AttrsLists.FindNodeOrInsertPos(ID, InsertPoint);
Cleanup whitespace. llvm-svn: 166013
2012-10-16 14:01:44 +08:00
Split param attr implementation out from Function.cpp into its own file. Don't #include ParameterAttributes.h into any major public header files: just move methods out of line as appropriate. llvm-svn: 45517
2008-01-03 07:42:30 +08:00
// If we didn't find any existing attributes of the same shape then
// create a new one and insert it.
Make the AttrListPtr object a part of the LLVMContext. When code deletes the context, the AttributeImpls that the AttrListPtr points to are now invalid. Therefore, instead of keeping a separate managed static for the AttrListPtrs that's reference counted, move it into the LLVMContext and delete it when deleting the AttributeImpls. llvm-svn: 168354
2012-11-20 13:09:20 +08:00
if (!PA) {
Rename AttributeSet to AttributeList Summary: This class is a list of AttributeSetNodes corresponding the function prototype of a call or function declaration. This class used to be called ParamAttrListPtr, then AttrListPtr, then AttributeSet. It is typically accessed by parameter and return value index, so "AttributeList" seems like a more intuitive name. Rename AttributeSetImpl to AttributeListImpl to follow suit. It's useful to rename this class so that we can rename AttributeSetNode to AttributeSet later. AttributeSet is the set of attributes that apply to a single function, argument, or return value. Reviewers: sanjoy, javed.absar, chandlerc, pete Reviewed By: pete Subscribers: pete, jholewinski, arsenm, dschuff, mehdi_amini, jfb, nhaehnle, sbc100, void, llvm-commits Differential Revision: https://reviews.llvm.org/D31102 llvm-svn: 298393
2017-03-22 00:57:19 +08:00
// Coallocate entries after the AttributeListImpl itself.
[IR] Make Attributes and AttributeLists trivially destructible and BumpPtrAllocate them
2020-05-01 20:12:17 +08:00
void *Mem = pImpl->Alloc.Allocate(
AttributeListImpl::totalSizeToAlloc<AttributeSet>(AttrSets.size()),
alignof(AttributeListImpl));
[IR] AttributeList::getContext has a single user, remove it.
2020-05-01 20:18:29 +08:00
PA = new (Mem) AttributeListImpl(AttrSets);
Make the AttrListPtr object a part of the LLVMContext. When code deletes the context, the AttributeImpls that the AttrListPtr points to are now invalid. Therefore, instead of keeping a separate managed static for the AttrListPtrs that's reference counted, move it into the LLVMContext and delete it when deleting the AttributeImpls. llvm-svn: 168354
2012-11-20 13:09:20 +08:00
pImpl->AttrsLists.InsertNode(PA, InsertPoint);
Split param attr implementation out from Function.cpp into its own file. Don't #include ParameterAttributes.h into any major public header files: just move methods out of line as appropriate. llvm-svn: 45517
2008-01-03 07:42:30 +08:00
}
Cleanup whitespace. llvm-svn: 166013
2012-10-16 14:01:44 +08:00
Large mechanical patch. s/ParamAttr/Attribute/g s/PAList/AttrList/g s/FnAttributeWithIndex/AttributeWithIndex/g s/FnAttr/Attribute/g This sets the stage - to implement function notes as function attributes and - to distinguish between function attributes and return value attributes. This requires corresponding changes in llvm-gcc and clang. llvm-svn: 56622
2008-09-26 05:00:45 +08:00
// Return the AttributesList that we found or created.
Rename AttributeSet to AttributeList Summary: This class is a list of AttributeSetNodes corresponding the function prototype of a call or function declaration. This class used to be called ParamAttrListPtr, then AttrListPtr, then AttributeSet. It is typically accessed by parameter and return value index, so "AttributeList" seems like a more intuitive name. Rename AttributeSetImpl to AttributeListImpl to follow suit. It's useful to rename this class so that we can rename AttributeSetNode to AttributeSet later. AttributeSet is the set of attributes that apply to a single function, argument, or return value. Reviewers: sanjoy, javed.absar, chandlerc, pete Reviewed By: pete Subscribers: pete, jholewinski, arsenm, dschuff, mehdi_amini, jfb, nhaehnle, sbc100, void, llvm-commits Differential Revision: https://reviews.llvm.org/D31102 llvm-svn: 298393
2017-03-22 00:57:19 +08:00
return AttributeList(PA);
Split param attr implementation out from Function.cpp into its own file. Don't #include ParameterAttributes.h into any major public header files: just move methods out of line as appropriate. llvm-svn: 45517
2008-01-03 07:42:30 +08:00
}
Rename AttributeSet to AttributeList Summary: This class is a list of AttributeSetNodes corresponding the function prototype of a call or function declaration. This class used to be called ParamAttrListPtr, then AttrListPtr, then AttributeSet. It is typically accessed by parameter and return value index, so "AttributeList" seems like a more intuitive name. Rename AttributeSetImpl to AttributeListImpl to follow suit. It's useful to rename this class so that we can rename AttributeSetNode to AttributeSet later. AttributeSet is the set of attributes that apply to a single function, argument, or return value. Reviewers: sanjoy, javed.absar, chandlerc, pete Reviewed By: pete Subscribers: pete, jholewinski, arsenm, dschuff, mehdi_amini, jfb, nhaehnle, sbc100, void, llvm-commits Differential Revision: https://reviews.llvm.org/D31102 llvm-svn: 298393
2017-03-22 00:57:19 +08:00
AttributeList
AttributeList::get(LLVMContext &C,
ArrayRef<std::pair<unsigned, Attribute>> Attrs) {
Remove the AttributeWithIndex class. The AttributeWithIndex class exposed the interior structure of the AttributeSet class. That was gross. Remove it and all of the code that relied upon it. llvm-svn: 173722
2013-01-29 05:55:20 +08:00
// If there are no attributes then return a null AttributesList pointer.
if (Attrs.empty())
[IR] Fix some Clang-tidy modernize-use-auto warnings; other minor fixes (NFC). llvm-svn: 328850
2018-03-30 08:47:31 +08:00
return {};
Remove the AttributeWithIndex class. The AttributeWithIndex class exposed the interior structure of the AttributeSet class. That was gross. Remove it and all of the code that relied upon it. llvm-svn: 173722
2013-01-29 05:55:20 +08:00
[ADT/STLExtras.h] - Add llvm::is_sorted wrapper and update callers. It can be used to avoid passing the begin and end of a range. This makes the code shorter and it is consistent with another wrappers we already have. Differential revision: https://reviews.llvm.org/D78016
2020-04-13 19:46:41 +08:00
assert(llvm::is_sorted(Attrs,
[](const std::pair<unsigned, Attribute> &LHS,
const std::pair<unsigned, Attribute> &RHS) {
return LHS.first < RHS.first;
}) &&
"Misordered Attributes list!");
[Attributes] Add a method to check if an Attribute has AttrKind None. Use instead of hasAttribute(Attribute::None) There's a special case in hasAttribute for None when pImpl is null. If pImpl is not null we dispatch to pImpl->hasAttribute which will always return false for Attribute::None. So if we just want to check for None its sufficient to just check that pImpl is null. Which can even be done inline. This patch adds a helper for that case which I hope will speed up our getSubtargetImpl implementations. Differential Revision: https://reviews.llvm.org/D86744
2020-08-29 04:02:42 +08:00
assert(llvm::all_of(Attrs,
[](const std::pair<unsigned, Attribute> &Pair) {
return Pair.second.isValid();
}) &&
Use range algorithms instead of unpacking begin/end No functionality change is intended. llvm-svn: 278417
2016-08-12 05:15:00 +08:00
"Pointless attribute!");
Remove the AttributeWithIndex class. The AttributeWithIndex class exposed the interior structure of the AttributeSet class. That was gross. Remove it and all of the code that relied upon it. llvm-svn: 173722
2013-01-29 05:55:20 +08:00
Try to appease some broken compilers by using 'unsigned' instead of 'uint64_t'. llvm-svn: 173725
2013-01-29 06:33:39 +08:00
// Create a vector if (unsigned, AttributeSetNode*) pairs from the attributes
Remove the AttributeWithIndex class. The AttributeWithIndex class exposed the interior structure of the AttributeSet class. That was gross. Remove it and all of the code that relied upon it. llvm-svn: 173722
2013-01-29 05:55:20 +08:00
// list.
[IR] Add AttributeSet to hide AttributeSetNode* again, NFC Summary: For now, it just wraps AttributeSetNode*. Eventually, it will hold AvailableAttrs as an inline bitset, and adding and removing enum attributes will be super cheap. This sinks AttributeSetNode back down to lib/IR/AttributeImpl.h. Reviewers: pete, chandlerc Subscribers: llvm-commits, jfb Differential Revision: https://reviews.llvm.org/D31940 llvm-svn: 300014
2017-04-12 08:38:00 +08:00
SmallVector<std::pair<unsigned, AttributeSet>, 8> AttrPairVec;
[IR] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC). llvm-svn: 295383
2017-02-17 08:00:09 +08:00
for (ArrayRef<std::pair<unsigned, Attribute>>::iterator I = Attrs.begin(),
Remove the AttributeWithIndex class. The AttributeWithIndex class exposed the interior structure of the AttributeSet class. That was gross. Remove it and all of the code that relied upon it. llvm-svn: 173722
2013-01-29 05:55:20 +08:00
E = Attrs.end(); I != E; ) {
Try to appease some broken compilers by using 'unsigned' instead of 'uint64_t'. llvm-svn: 173725
2013-01-29 06:33:39 +08:00
unsigned Index = I->first;
Remove the AttributeWithIndex class. The AttributeWithIndex class exposed the interior structure of the AttributeSet class. That was gross. Remove it and all of the code that relied upon it. llvm-svn: 173722
2013-01-29 05:55:20 +08:00
SmallVector<Attribute, 4> AttrVec;
AttributeSet::get(): Fix a valgrind error. It doesn't affect actual behavior, though. Don't touch I->first on the end iterator, I == E! llvm-svn: 173804
2013-01-29 23:18:16 +08:00
while (I != E && I->first == Index) {
Remove the AttributeWithIndex class. The AttributeWithIndex class exposed the interior structure of the AttributeSet class. That was gross. Remove it and all of the code that relied upon it. llvm-svn: 173722
2013-01-29 05:55:20 +08:00
AttrVec.push_back(I->second);
++I;
}
[IR] Add AttributeSet to hide AttributeSetNode* again, NFC Summary: For now, it just wraps AttributeSetNode*. Eventually, it will hold AvailableAttrs as an inline bitset, and adding and removing enum attributes will be super cheap. This sinks AttributeSetNode back down to lib/IR/AttributeImpl.h. Reviewers: pete, chandlerc Subscribers: llvm-commits, jfb Differential Revision: https://reviews.llvm.org/D31940 llvm-svn: 300014
2017-04-12 08:38:00 +08:00
AttrPairVec.emplace_back(Index, AttributeSet::get(C, AttrVec));
Remove the AttributeWithIndex class. The AttributeWithIndex class exposed the interior structure of the AttributeSet class. That was gross. Remove it and all of the code that relied upon it. llvm-svn: 173722
2013-01-29 05:55:20 +08:00
}
[IR] Switch AttributeList to use an array for O(1) access Summary: Before this change, AttributeLists stored a pair of index and AttributeSet. This is memory efficient if most arguments do not have attributes. However, it requires doing a search over the pairs to test an argument or function attribute. Profiling shows that this loop was 0.76% of the time in 'opt -O2' of sqlite3.c, because LLVM constantly tests values for nullability. This was worth about 2.5% of mid-level optimization cycles on the sqlite3 amalgamation. Here are the full perf results: https://reviews.llvm.org/P7995 Here are just the before and after cycle counts: ``` $ perf stat -r 5 ./opt_before -O2 sqlite3.bc -o /dev/null 13,274,181,184 cycles # 3.047 GHz ( +- 0.28% ) $ perf stat -r 5 ./opt_after -O2 sqlite3.bc -o /dev/null 12,906,927,263 cycles # 3.043 GHz ( +- 0.51% ) ``` This patch *does not* change the indices used to query attributes, as requested by reviewers. Tracking whether an index is usable for array indexing is a huge pain that affects many of the internal APIs, so it would be good to come back later and do a cleanup to remove this internal adjustment. Reviewers: pete, chandlerc Subscribers: javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D32819 llvm-svn: 303654
2017-05-24 01:01:48 +08:00
return get(C, AttrPairVec);
Remove the AttributeWithIndex class. The AttributeWithIndex class exposed the interior structure of the AttributeSet class. That was gross. Remove it and all of the code that relied upon it. llvm-svn: 173722
2013-01-29 05:55:20 +08:00
}
Rename AttributeSet to AttributeList Summary: This class is a list of AttributeSetNodes corresponding the function prototype of a call or function declaration. This class used to be called ParamAttrListPtr, then AttrListPtr, then AttributeSet. It is typically accessed by parameter and return value index, so "AttributeList" seems like a more intuitive name. Rename AttributeSetImpl to AttributeListImpl to follow suit. It's useful to rename this class so that we can rename AttributeSetNode to AttributeSet later. AttributeSet is the set of attributes that apply to a single function, argument, or return value. Reviewers: sanjoy, javed.absar, chandlerc, pete Reviewed By: pete Subscribers: pete, jholewinski, arsenm, dschuff, mehdi_amini, jfb, nhaehnle, sbc100, void, llvm-commits Differential Revision: https://reviews.llvm.org/D31102 llvm-svn: 298393
2017-03-22 00:57:19 +08:00
AttributeList
AttributeList::get(LLVMContext &C,
[IR] Add AttributeSet to hide AttributeSetNode* again, NFC Summary: For now, it just wraps AttributeSetNode*. Eventually, it will hold AvailableAttrs as an inline bitset, and adding and removing enum attributes will be super cheap. This sinks AttributeSetNode back down to lib/IR/AttributeImpl.h. Reviewers: pete, chandlerc Subscribers: llvm-commits, jfb Differential Revision: https://reviews.llvm.org/D31940 llvm-svn: 300014
2017-04-12 08:38:00 +08:00
ArrayRef<std::pair<unsigned, AttributeSet>> Attrs) {
Remove the AttributeWithIndex class. The AttributeWithIndex class exposed the interior structure of the AttributeSet class. That was gross. Remove it and all of the code that relied upon it. llvm-svn: 173722
2013-01-29 05:55:20 +08:00
// If there are no attributes then return a null AttributesList pointer.
if (Attrs.empty())
[IR] Fix some Clang-tidy modernize-use-auto warnings; other minor fixes (NFC). llvm-svn: 328850
2018-03-30 08:47:31 +08:00
return {};
Remove the AttributeWithIndex class. The AttributeWithIndex class exposed the interior structure of the AttributeSet class. That was gross. Remove it and all of the code that relied upon it. llvm-svn: 173722
2013-01-29 05:55:20 +08:00
[ADT/STLExtras.h] - Add llvm::is_sorted wrapper and update callers. It can be used to avoid passing the begin and end of a range. This makes the code shorter and it is consistent with another wrappers we already have. Differential revision: https://reviews.llvm.org/D78016
2020-04-13 19:46:41 +08:00
assert(llvm::is_sorted(Attrs,
[](const std::pair<unsigned, AttributeSet> &LHS,
const std::pair<unsigned, AttributeSet> &RHS) {
return LHS.first < RHS.first;
}) &&
[IR] Switch AttributeList to use an array for O(1) access Summary: Before this change, AttributeLists stored a pair of index and AttributeSet. This is memory efficient if most arguments do not have attributes. However, it requires doing a search over the pairs to test an argument or function attribute. Profiling shows that this loop was 0.76% of the time in 'opt -O2' of sqlite3.c, because LLVM constantly tests values for nullability. This was worth about 2.5% of mid-level optimization cycles on the sqlite3 amalgamation. Here are the full perf results: https://reviews.llvm.org/P7995 Here are just the before and after cycle counts: ``` $ perf stat -r 5 ./opt_before -O2 sqlite3.bc -o /dev/null 13,274,181,184 cycles # 3.047 GHz ( +- 0.28% ) $ perf stat -r 5 ./opt_after -O2 sqlite3.bc -o /dev/null 12,906,927,263 cycles # 3.043 GHz ( +- 0.51% ) ``` This patch *does not* change the indices used to query attributes, as requested by reviewers. Tracking whether an index is usable for array indexing is a huge pain that affects many of the internal APIs, so it would be good to come back later and do a cleanup to remove this internal adjustment. Reviewers: pete, chandlerc Subscribers: javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D32819 llvm-svn: 303654
2017-05-24 01:01:48 +08:00
"Misordered Attributes list!");
[IR] Fix some Clang-tidy modernize-use-auto warnings; other minor fixes (NFC). llvm-svn: 328850
2018-03-30 08:47:31 +08:00
assert(llvm::none_of(Attrs,
[](const std::pair<unsigned, AttributeSet> &Pair) {
return !Pair.second.hasAttributes();
}) &&
[IR] Switch AttributeList to use an array for O(1) access Summary: Before this change, AttributeLists stored a pair of index and AttributeSet. This is memory efficient if most arguments do not have attributes. However, it requires doing a search over the pairs to test an argument or function attribute. Profiling shows that this loop was 0.76% of the time in 'opt -O2' of sqlite3.c, because LLVM constantly tests values for nullability. This was worth about 2.5% of mid-level optimization cycles on the sqlite3 amalgamation. Here are the full perf results: https://reviews.llvm.org/P7995 Here are just the before and after cycle counts: ``` $ perf stat -r 5 ./opt_before -O2 sqlite3.bc -o /dev/null 13,274,181,184 cycles # 3.047 GHz ( +- 0.28% ) $ perf stat -r 5 ./opt_after -O2 sqlite3.bc -o /dev/null 12,906,927,263 cycles # 3.043 GHz ( +- 0.51% ) ``` This patch *does not* change the indices used to query attributes, as requested by reviewers. Tracking whether an index is usable for array indexing is a huge pain that affects many of the internal APIs, so it would be good to come back later and do a cleanup to remove this internal adjustment. Reviewers: pete, chandlerc Subscribers: javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D32819 llvm-svn: 303654
2017-05-24 01:01:48 +08:00
"Pointless attribute!");
unsigned MaxIndex = Attrs.back().first;
[Attributes] Fix a bug in AttributeList::get so it can handle a mix of FunctionIndex and ReturnIndex/arg indices at the same time The code uses the index of the last element in the sorted array to determine the maximum size needed for the vector. But if the last index is a FunctionIndex(~0), attrIdxToArrayIdx will return 0 and the vector will have size 1. If there are any indices before FunctionIndex, those values would return a value larger than 0 from attrIdxToArrayIdx. So in this case we need to look in front of the FunctionIndex to get the true size needed. Differential Revision: https://reviews.llvm.org/D45632 llvm-svn: 330136
2018-04-17 01:05:01 +08:00
// If the MaxIndex is FunctionIndex and there are other indices in front
// of it, we need to use the largest of those to get the right size.
if (MaxIndex == FunctionIndex && Attrs.size() > 1)
MaxIndex = Attrs[Attrs.size() - 2].first;
[IR] Switch AttributeList to use an array for O(1) access Summary: Before this change, AttributeLists stored a pair of index and AttributeSet. This is memory efficient if most arguments do not have attributes. However, it requires doing a search over the pairs to test an argument or function attribute. Profiling shows that this loop was 0.76% of the time in 'opt -O2' of sqlite3.c, because LLVM constantly tests values for nullability. This was worth about 2.5% of mid-level optimization cycles on the sqlite3 amalgamation. Here are the full perf results: https://reviews.llvm.org/P7995 Here are just the before and after cycle counts: ``` $ perf stat -r 5 ./opt_before -O2 sqlite3.bc -o /dev/null 13,274,181,184 cycles # 3.047 GHz ( +- 0.28% ) $ perf stat -r 5 ./opt_after -O2 sqlite3.bc -o /dev/null 12,906,927,263 cycles # 3.043 GHz ( +- 0.51% ) ``` This patch *does not* change the indices used to query attributes, as requested by reviewers. Tracking whether an index is usable for array indexing is a huge pain that affects many of the internal APIs, so it would be good to come back later and do a cleanup to remove this internal adjustment. Reviewers: pete, chandlerc Subscribers: javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D32819 llvm-svn: 303654
2017-05-24 01:01:48 +08:00
SmallVector<AttributeSet, 4> AttrVec(attrIdxToArrayIdx(MaxIndex) + 1);
[IR] Use a reference in a range-based for This avoids unneeded copies when using a range-based for loops. This avoids new warnings due to D68912 adds -Wrange-loop-analysis to -Wall. Differential Revision: https://reviews.llvm.org/D70870
2019-12-18 04:57:58 +08:00
for (const auto &Pair : Attrs)
[IR] Switch AttributeList to use an array for O(1) access Summary: Before this change, AttributeLists stored a pair of index and AttributeSet. This is memory efficient if most arguments do not have attributes. However, it requires doing a search over the pairs to test an argument or function attribute. Profiling shows that this loop was 0.76% of the time in 'opt -O2' of sqlite3.c, because LLVM constantly tests values for nullability. This was worth about 2.5% of mid-level optimization cycles on the sqlite3 amalgamation. Here are the full perf results: https://reviews.llvm.org/P7995 Here are just the before and after cycle counts: ``` $ perf stat -r 5 ./opt_before -O2 sqlite3.bc -o /dev/null 13,274,181,184 cycles # 3.047 GHz ( +- 0.28% ) $ perf stat -r 5 ./opt_after -O2 sqlite3.bc -o /dev/null 12,906,927,263 cycles # 3.043 GHz ( +- 0.51% ) ``` This patch *does not* change the indices used to query attributes, as requested by reviewers. Tracking whether an index is usable for array indexing is a huge pain that affects many of the internal APIs, so it would be good to come back later and do a cleanup to remove this internal adjustment. Reviewers: pete, chandlerc Subscribers: javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D32819 llvm-svn: 303654
2017-05-24 01:01:48 +08:00
AttrVec[attrIdxToArrayIdx(Pair.first)] = Pair.second;
return getImpl(C, AttrVec);
Remove the AttributeWithIndex class. The AttributeWithIndex class exposed the interior structure of the AttributeSet class. That was gross. Remove it and all of the code that relied upon it. llvm-svn: 173722
2013-01-29 05:55:20 +08:00
}
[IR] Take func, ret, and arg attrs separately in AttributeList::get This seems like a much more natural API, based on Derek Schuff's comments on r300015. It further hides the implementation detail of AttributeList that function attributes come last and appear at index ~0U, which is easy for the user to screw up. git diff says it saves code as well: 97 insertions(+), 137 deletions(-) This also makes it easier to change the implementation, which I want to do next. llvm-svn: 300153
2017-04-13 08:58:09 +08:00
AttributeList AttributeList::get(LLVMContext &C, AttributeSet FnAttrs,
AttributeSet RetAttrs,
ArrayRef<AttributeSet> ArgAttrs) {
[IR] Switch AttributeList to use an array for O(1) access Summary: Before this change, AttributeLists stored a pair of index and AttributeSet. This is memory efficient if most arguments do not have attributes. However, it requires doing a search over the pairs to test an argument or function attribute. Profiling shows that this loop was 0.76% of the time in 'opt -O2' of sqlite3.c, because LLVM constantly tests values for nullability. This was worth about 2.5% of mid-level optimization cycles on the sqlite3 amalgamation. Here are the full perf results: https://reviews.llvm.org/P7995 Here are just the before and after cycle counts: ``` $ perf stat -r 5 ./opt_before -O2 sqlite3.bc -o /dev/null 13,274,181,184 cycles # 3.047 GHz ( +- 0.28% ) $ perf stat -r 5 ./opt_after -O2 sqlite3.bc -o /dev/null 12,906,927,263 cycles # 3.043 GHz ( +- 0.51% ) ``` This patch *does not* change the indices used to query attributes, as requested by reviewers. Tracking whether an index is usable for array indexing is a huge pain that affects many of the internal APIs, so it would be good to come back later and do a cleanup to remove this internal adjustment. Reviewers: pete, chandlerc Subscribers: javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D32819 llvm-svn: 303654
2017-05-24 01:01:48 +08:00
// Scan from the end to find the last argument with attributes. Most
// arguments don't have attributes, so it's nice if we can have fewer unique
// AttributeListImpls by dropping empty attribute sets at the end of the list.
unsigned NumSets = 0;
for (size_t I = ArgAttrs.size(); I != 0; --I) {
if (ArgAttrs[I - 1].hasAttributes()) {
NumSets = I + 2;
break;
}
}
if (NumSets == 0) {
// Check function and return attributes if we didn't have argument
// attributes.
if (RetAttrs.hasAttributes())
NumSets = 2;
else if (FnAttrs.hasAttributes())
NumSets = 1;
Reland "[IR] Make AttributeSetNode public, avoid temporary AttributeList copies" This re-lands r299875. I introduced a bug in Clang code responsible for replacing K&R, no prototype declarations with a real function definition with a prototype. The bug was here: // Collect any return attributes from the call. - if (oldAttrs.hasAttributes(llvm::AttributeList::ReturnIndex)) - newAttrs.push_back(llvm::AttributeList::get(newFn->getContext(), - oldAttrs.getRetAttributes())); + newAttrs.push_back(oldAttrs.getRetAttributes()); Previously getRetAttributes() carried AttributeList::ReturnIndex in its AttributeList. Now that we return the AttributeSetNode* directly, it no longer carries that index, and we call this overload with a single node: AttributeList::get(LLVMContext&, ArrayRef<AttributeSetNode*>) That aborted with an assertion on x86_32 targets. I added an explicit triple to the test and added CHECKs to help find issues like this in the future sooner. llvm-svn: 299899
2017-04-11 07:31:05 +08:00
}
[IR] Switch AttributeList to use an array for O(1) access Summary: Before this change, AttributeLists stored a pair of index and AttributeSet. This is memory efficient if most arguments do not have attributes. However, it requires doing a search over the pairs to test an argument or function attribute. Profiling shows that this loop was 0.76% of the time in 'opt -O2' of sqlite3.c, because LLVM constantly tests values for nullability. This was worth about 2.5% of mid-level optimization cycles on the sqlite3 amalgamation. Here are the full perf results: https://reviews.llvm.org/P7995 Here are just the before and after cycle counts: ``` $ perf stat -r 5 ./opt_before -O2 sqlite3.bc -o /dev/null 13,274,181,184 cycles # 3.047 GHz ( +- 0.28% ) $ perf stat -r 5 ./opt_after -O2 sqlite3.bc -o /dev/null 12,906,927,263 cycles # 3.043 GHz ( +- 0.51% ) ``` This patch *does not* change the indices used to query attributes, as requested by reviewers. Tracking whether an index is usable for array indexing is a huge pain that affects many of the internal APIs, so it would be good to come back later and do a cleanup to remove this internal adjustment. Reviewers: pete, chandlerc Subscribers: javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D32819 llvm-svn: 303654
2017-05-24 01:01:48 +08:00
// If all attribute sets were empty, we can use the empty attribute list.
if (NumSets == 0)
[IR] Fix some Clang-tidy modernize-use-auto warnings; other minor fixes (NFC). llvm-svn: 328850
2018-03-30 08:47:31 +08:00
return {};
[IR] Switch AttributeList to use an array for O(1) access Summary: Before this change, AttributeLists stored a pair of index and AttributeSet. This is memory efficient if most arguments do not have attributes. However, it requires doing a search over the pairs to test an argument or function attribute. Profiling shows that this loop was 0.76% of the time in 'opt -O2' of sqlite3.c, because LLVM constantly tests values for nullability. This was worth about 2.5% of mid-level optimization cycles on the sqlite3 amalgamation. Here are the full perf results: https://reviews.llvm.org/P7995 Here are just the before and after cycle counts: ``` $ perf stat -r 5 ./opt_before -O2 sqlite3.bc -o /dev/null 13,274,181,184 cycles # 3.047 GHz ( +- 0.28% ) $ perf stat -r 5 ./opt_after -O2 sqlite3.bc -o /dev/null 12,906,927,263 cycles # 3.043 GHz ( +- 0.51% ) ``` This patch *does not* change the indices used to query attributes, as requested by reviewers. Tracking whether an index is usable for array indexing is a huge pain that affects many of the internal APIs, so it would be good to come back later and do a cleanup to remove this internal adjustment. Reviewers: pete, chandlerc Subscribers: javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D32819 llvm-svn: 303654
2017-05-24 01:01:48 +08:00
SmallVector<AttributeSet, 8> AttrSets;
AttrSets.reserve(NumSets);
// If we have any attributes, we always have function attributes.
AttrSets.push_back(FnAttrs);
if (NumSets > 1)
AttrSets.push_back(RetAttrs);
if (NumSets > 2) {
// Drop the empty argument attribute sets at the end.
ArgAttrs = ArgAttrs.take_front(NumSets - 2);
[llvm] Use llvm::append_range (NFC)
2021-01-07 10:27:33 +08:00
llvm::append_range(AttrSets, ArgAttrs);
[IR] Switch AttributeList to use an array for O(1) access Summary: Before this change, AttributeLists stored a pair of index and AttributeSet. This is memory efficient if most arguments do not have attributes. However, it requires doing a search over the pairs to test an argument or function attribute. Profiling shows that this loop was 0.76% of the time in 'opt -O2' of sqlite3.c, because LLVM constantly tests values for nullability. This was worth about 2.5% of mid-level optimization cycles on the sqlite3 amalgamation. Here are the full perf results: https://reviews.llvm.org/P7995 Here are just the before and after cycle counts: ``` $ perf stat -r 5 ./opt_before -O2 sqlite3.bc -o /dev/null 13,274,181,184 cycles # 3.047 GHz ( +- 0.28% ) $ perf stat -r 5 ./opt_after -O2 sqlite3.bc -o /dev/null 12,906,927,263 cycles # 3.043 GHz ( +- 0.51% ) ``` This patch *does not* change the indices used to query attributes, as requested by reviewers. Tracking whether an index is usable for array indexing is a huge pain that affects many of the internal APIs, so it would be good to come back later and do a cleanup to remove this internal adjustment. Reviewers: pete, chandlerc Subscribers: javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D32819 llvm-svn: 303654
2017-05-24 01:01:48 +08:00
}
return getImpl(C, AttrSets);
Reland "[IR] Make AttributeSetNode public, avoid temporary AttributeList copies" This re-lands r299875. I introduced a bug in Clang code responsible for replacing K&R, no prototype declarations with a real function definition with a prototype. The bug was here: // Collect any return attributes from the call. - if (oldAttrs.hasAttributes(llvm::AttributeList::ReturnIndex)) - newAttrs.push_back(llvm::AttributeList::get(newFn->getContext(), - oldAttrs.getRetAttributes())); + newAttrs.push_back(oldAttrs.getRetAttributes()); Previously getRetAttributes() carried AttributeList::ReturnIndex in its AttributeList. Now that we return the AttributeSetNode* directly, it no longer carries that index, and we call this overload with a single node: AttributeList::get(LLVMContext&, ArrayRef<AttributeSetNode*>) That aborted with an assertion on x86_32 targets. I added an explicit triple to the test and added CHECKs to help find issues like this in the future sooner. llvm-svn: 299899
2017-04-11 07:31:05 +08:00
}
Rename AttributeSet to AttributeList Summary: This class is a list of AttributeSetNodes corresponding the function prototype of a call or function declaration. This class used to be called ParamAttrListPtr, then AttrListPtr, then AttributeSet. It is typically accessed by parameter and return value index, so "AttributeList" seems like a more intuitive name. Rename AttributeSetImpl to AttributeListImpl to follow suit. It's useful to rename this class so that we can rename AttributeSetNode to AttributeSet later. AttributeSet is the set of attributes that apply to a single function, argument, or return value. Reviewers: sanjoy, javed.absar, chandlerc, pete Reviewed By: pete Subscribers: pete, jholewinski, arsenm, dschuff, mehdi_amini, jfb, nhaehnle, sbc100, void, llvm-commits Differential Revision: https://reviews.llvm.org/D31102 llvm-svn: 298393
2017-03-22 00:57:19 +08:00
AttributeList AttributeList::get(LLVMContext &C, unsigned Index,
const AttrBuilder &B) {
Have AttributeSet::getRetAttributes() return an AttributeSet instead of Attribute. This further restricts the use of the Attribute class to the Attribute family of classes. llvm-svn: 173098
2013-01-22 06:44:49 +08:00
if (!B.hasAttributes())
[IR] Fix some Clang-tidy modernize-use-auto warnings; other minor fixes (NFC). llvm-svn: 328850
2018-03-30 08:47:31 +08:00
return {};
[IR] Switch AttributeList to use an array for O(1) access Summary: Before this change, AttributeLists stored a pair of index and AttributeSet. This is memory efficient if most arguments do not have attributes. However, it requires doing a search over the pairs to test an argument or function attribute. Profiling shows that this loop was 0.76% of the time in 'opt -O2' of sqlite3.c, because LLVM constantly tests values for nullability. This was worth about 2.5% of mid-level optimization cycles on the sqlite3 amalgamation. Here are the full perf results: https://reviews.llvm.org/P7995 Here are just the before and after cycle counts: ``` $ perf stat -r 5 ./opt_before -O2 sqlite3.bc -o /dev/null 13,274,181,184 cycles # 3.047 GHz ( +- 0.28% ) $ perf stat -r 5 ./opt_after -O2 sqlite3.bc -o /dev/null 12,906,927,263 cycles # 3.043 GHz ( +- 0.51% ) ``` This patch *does not* change the indices used to query attributes, as requested by reviewers. Tracking whether an index is usable for array indexing is a huge pain that affects many of the internal APIs, so it would be good to come back later and do a cleanup to remove this internal adjustment. Reviewers: pete, chandlerc Subscribers: javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D32819 llvm-svn: 303654
2017-05-24 01:01:48 +08:00
Index = attrIdxToArrayIdx(Index);
SmallVector<AttributeSet, 8> AttrSets(Index + 1);
AttrSets[Index] = AttributeSet::get(C, B);
return getImpl(C, AttrSets);
Add a method to create an AttributeSet from an AttrBuilder. The Attribute class is eventually going to represent one attribute. So we need this class to create the set of attributes. Add some iterator methods to the builder to access its internal bits in a nice way. llvm-svn: 171586
2013-01-05 09:36:54 +08:00
}
Rename AttributeSet to AttributeList Summary: This class is a list of AttributeSetNodes corresponding the function prototype of a call or function declaration. This class used to be called ParamAttrListPtr, then AttrListPtr, then AttributeSet. It is typically accessed by parameter and return value index, so "AttributeList" seems like a more intuitive name. Rename AttributeSetImpl to AttributeListImpl to follow suit. It's useful to rename this class so that we can rename AttributeSetNode to AttributeSet later. AttributeSet is the set of attributes that apply to a single function, argument, or return value. Reviewers: sanjoy, javed.absar, chandlerc, pete Reviewed By: pete Subscribers: pete, jholewinski, arsenm, dschuff, mehdi_amini, jfb, nhaehnle, sbc100, void, llvm-commits Differential Revision: https://reviews.llvm.org/D31102 llvm-svn: 298393
2017-03-22 00:57:19 +08:00
AttributeList AttributeList::get(LLVMContext &C, unsigned Index,
ArrayRef<Attribute::AttrKind> Kinds) {
Try to appease some broken compilers by using 'unsigned' instead of 'uint64_t'. llvm-svn: 173725
2013-01-29 06:33:39 +08:00
SmallVector<std::pair<unsigned, Attribute>, 8> Attrs;
[IR] Fix some Clang-tidy modernize-use-auto warnings; other minor fixes (NFC). llvm-svn: 328850
2018-03-30 08:47:31 +08:00
for (const auto K : Kinds)
Use range algorithms instead of unpacking begin/end No functionality change is intended. llvm-svn: 278417
2016-08-12 05:15:00 +08:00
Attrs.emplace_back(Index, Attribute::get(C, K));
Remove the AttributeWithIndex class. The AttributeWithIndex class exposed the interior structure of the AttributeSet class. That was gross. Remove it and all of the code that relied upon it. llvm-svn: 173722
2013-01-29 05:55:20 +08:00
return get(C, Attrs);
Remove the last of uses that use the Attribute object as a collection of attributes. Collections of attributes are handled via the AttributeSet class now. This finally frees us up to make significant changes to how attributes are structured. llvm-svn: 173228
2013-01-23 14:14:59 +08:00
}
Enable `align <n>` to be used in the intrinsic definition. - This allow us to specify the (minimal) alignment on an intrinsic's arguments and, more importantly, the return value. Differential Revision: https://reviews.llvm.org/D80422
2020-05-28 04:02:15 +08:00
AttributeList AttributeList::get(LLVMContext &C, unsigned Index,
ArrayRef<Attribute::AttrKind> Kinds,
ArrayRef<uint64_t> Values) {
assert(Kinds.size() == Values.size() && "Mismatched attribute values.");
SmallVector<std::pair<unsigned, Attribute>, 8> Attrs;
auto VI = Values.begin();
for (const auto K : Kinds)
Attrs.emplace_back(Index, Attribute::get(C, K, *VI++));
return get(C, Attrs);
}
Rename AttributeSet to AttributeList Summary: This class is a list of AttributeSetNodes corresponding the function prototype of a call or function declaration. This class used to be called ParamAttrListPtr, then AttrListPtr, then AttributeSet. It is typically accessed by parameter and return value index, so "AttributeList" seems like a more intuitive name. Rename AttributeSetImpl to AttributeListImpl to follow suit. It's useful to rename this class so that we can rename AttributeSetNode to AttributeSet later. AttributeSet is the set of attributes that apply to a single function, argument, or return value. Reviewers: sanjoy, javed.absar, chandlerc, pete Reviewed By: pete Subscribers: pete, jholewinski, arsenm, dschuff, mehdi_amini, jfb, nhaehnle, sbc100, void, llvm-commits Differential Revision: https://reviews.llvm.org/D31102 llvm-svn: 298393
2017-03-22 00:57:19 +08:00
AttributeList AttributeList::get(LLVMContext &C, unsigned Index,
ArrayRef<StringRef> Kinds) {
Add support for string attributes in the C API. Summary: As per title. This completes the C API Attribute support. Reviewers: Wallbraker, whitequark, echristo, rafael, jyknight Subscribers: mehdi_amini Differential Revision: http://reviews.llvm.org/D21365 llvm-svn: 272811
2016-06-16 01:50:39 +08:00
SmallVector<std::pair<unsigned, Attribute>, 8> Attrs;
[IR] Use a reference in a range-based for This avoids unneeded copies when using a range-based for loops. This avoids new warnings due to D68912 adds -Wrange-loop-analysis to -Wall. Differential Revision: https://reviews.llvm.org/D70870
2019-12-18 04:57:58 +08:00
for (const auto &K : Kinds)
Use range algorithms instead of unpacking begin/end No functionality change is intended. llvm-svn: 278417
2016-08-12 05:15:00 +08:00
Attrs.emplace_back(Index, Attribute::get(C, K));
Add support for string attributes in the C API. Summary: As per title. This completes the C API Attribute support. Reviewers: Wallbraker, whitequark, echristo, rafael, jyknight Subscribers: mehdi_amini Differential Revision: http://reviews.llvm.org/D21365 llvm-svn: 272811
2016-06-16 01:50:39 +08:00
return get(C, Attrs);
}
Rename AttributeSet to AttributeList Summary: This class is a list of AttributeSetNodes corresponding the function prototype of a call or function declaration. This class used to be called ParamAttrListPtr, then AttrListPtr, then AttributeSet. It is typically accessed by parameter and return value index, so "AttributeList" seems like a more intuitive name. Rename AttributeSetImpl to AttributeListImpl to follow suit. It's useful to rename this class so that we can rename AttributeSetNode to AttributeSet later. AttributeSet is the set of attributes that apply to a single function, argument, or return value. Reviewers: sanjoy, javed.absar, chandlerc, pete Reviewed By: pete Subscribers: pete, jholewinski, arsenm, dschuff, mehdi_amini, jfb, nhaehnle, sbc100, void, llvm-commits Differential Revision: https://reviews.llvm.org/D31102 llvm-svn: 298393
2017-03-22 00:57:19 +08:00
AttributeList AttributeList::get(LLVMContext &C,
ArrayRef<AttributeList> Attrs) {
if (Attrs.empty())
[IR] Fix some Clang-tidy modernize-use-auto warnings; other minor fixes (NFC). llvm-svn: 328850
2018-03-30 08:47:31 +08:00
return {};
[IR] Switch AttributeList to use an array for O(1) access Summary: Before this change, AttributeLists stored a pair of index and AttributeSet. This is memory efficient if most arguments do not have attributes. However, it requires doing a search over the pairs to test an argument or function attribute. Profiling shows that this loop was 0.76% of the time in 'opt -O2' of sqlite3.c, because LLVM constantly tests values for nullability. This was worth about 2.5% of mid-level optimization cycles on the sqlite3 amalgamation. Here are the full perf results: https://reviews.llvm.org/P7995 Here are just the before and after cycle counts: ``` $ perf stat -r 5 ./opt_before -O2 sqlite3.bc -o /dev/null 13,274,181,184 cycles # 3.047 GHz ( +- 0.28% ) $ perf stat -r 5 ./opt_after -O2 sqlite3.bc -o /dev/null 12,906,927,263 cycles # 3.043 GHz ( +- 0.51% ) ``` This patch *does not* change the indices used to query attributes, as requested by reviewers. Tracking whether an index is usable for array indexing is a huge pain that affects many of the internal APIs, so it would be good to come back later and do a cleanup to remove this internal adjustment. Reviewers: pete, chandlerc Subscribers: javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D32819 llvm-svn: 303654
2017-05-24 01:01:48 +08:00
if (Attrs.size() == 1)
return Attrs[0];
unsigned MaxSize = 0;
[IR] Use a reference in a range-based for This avoids unneeded copies when using a range-based for loops. This avoids new warnings due to D68912 adds -Wrange-loop-analysis to -Wall. Differential Revision: https://reviews.llvm.org/D70870
2019-12-18 04:57:58 +08:00
for (const auto &List : Attrs)
[IR] Switch AttributeList to use an array for O(1) access Summary: Before this change, AttributeLists stored a pair of index and AttributeSet. This is memory efficient if most arguments do not have attributes. However, it requires doing a search over the pairs to test an argument or function attribute. Profiling shows that this loop was 0.76% of the time in 'opt -O2' of sqlite3.c, because LLVM constantly tests values for nullability. This was worth about 2.5% of mid-level optimization cycles on the sqlite3 amalgamation. Here are the full perf results: https://reviews.llvm.org/P7995 Here are just the before and after cycle counts: ``` $ perf stat -r 5 ./opt_before -O2 sqlite3.bc -o /dev/null 13,274,181,184 cycles # 3.047 GHz ( +- 0.28% ) $ perf stat -r 5 ./opt_after -O2 sqlite3.bc -o /dev/null 12,906,927,263 cycles # 3.043 GHz ( +- 0.51% ) ``` This patch *does not* change the indices used to query attributes, as requested by reviewers. Tracking whether an index is usable for array indexing is a huge pain that affects many of the internal APIs, so it would be good to come back later and do a cleanup to remove this internal adjustment. Reviewers: pete, chandlerc Subscribers: javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D32819 llvm-svn: 303654
2017-05-24 01:01:48 +08:00
MaxSize = std::max(MaxSize, List.getNumAttrSets());
Fix assertion when merging multiple empty AttributeLists Patch by Nicholas Wilson! Differential Revision: https://reviews.llvm.org/D33627 llvm-svn: 304300
2017-05-31 22:24:06 +08:00
// If every list was empty, there is no point in merging the lists.
if (MaxSize == 0)
[IR] Fix some Clang-tidy modernize-use-auto warnings; other minor fixes (NFC). llvm-svn: 328850
2018-03-30 08:47:31 +08:00
return {};
Fix assertion when merging multiple empty AttributeLists Patch by Nicholas Wilson! Differential Revision: https://reviews.llvm.org/D33627 llvm-svn: 304300
2017-05-31 22:24:06 +08:00
[IR] Switch AttributeList to use an array for O(1) access Summary: Before this change, AttributeLists stored a pair of index and AttributeSet. This is memory efficient if most arguments do not have attributes. However, it requires doing a search over the pairs to test an argument or function attribute. Profiling shows that this loop was 0.76% of the time in 'opt -O2' of sqlite3.c, because LLVM constantly tests values for nullability. This was worth about 2.5% of mid-level optimization cycles on the sqlite3 amalgamation. Here are the full perf results: https://reviews.llvm.org/P7995 Here are just the before and after cycle counts: ``` $ perf stat -r 5 ./opt_before -O2 sqlite3.bc -o /dev/null 13,274,181,184 cycles # 3.047 GHz ( +- 0.28% ) $ perf stat -r 5 ./opt_after -O2 sqlite3.bc -o /dev/null 12,906,927,263 cycles # 3.043 GHz ( +- 0.51% ) ``` This patch *does not* change the indices used to query attributes, as requested by reviewers. Tracking whether an index is usable for array indexing is a huge pain that affects many of the internal APIs, so it would be good to come back later and do a cleanup to remove this internal adjustment. Reviewers: pete, chandlerc Subscribers: javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D32819 llvm-svn: 303654
2017-05-24 01:01:48 +08:00
SmallVector<AttributeSet, 8> NewAttrSets(MaxSize);
for (unsigned I = 0; I < MaxSize; ++I) {
AttrBuilder CurBuilder;
[IR] Use a reference in a range-based for This avoids unneeded copies when using a range-based for loops. This avoids new warnings due to D68912 adds -Wrange-loop-analysis to -Wall. Differential Revision: https://reviews.llvm.org/D70870
2019-12-18 04:57:58 +08:00
for (const auto &List : Attrs)
[IR] Switch AttributeList to use an array for O(1) access Summary: Before this change, AttributeLists stored a pair of index and AttributeSet. This is memory efficient if most arguments do not have attributes. However, it requires doing a search over the pairs to test an argument or function attribute. Profiling shows that this loop was 0.76% of the time in 'opt -O2' of sqlite3.c, because LLVM constantly tests values for nullability. This was worth about 2.5% of mid-level optimization cycles on the sqlite3 amalgamation. Here are the full perf results: https://reviews.llvm.org/P7995 Here are just the before and after cycle counts: ``` $ perf stat -r 5 ./opt_before -O2 sqlite3.bc -o /dev/null 13,274,181,184 cycles # 3.047 GHz ( +- 0.28% ) $ perf stat -r 5 ./opt_after -O2 sqlite3.bc -o /dev/null 12,906,927,263 cycles # 3.043 GHz ( +- 0.51% ) ``` This patch *does not* change the indices used to query attributes, as requested by reviewers. Tracking whether an index is usable for array indexing is a huge pain that affects many of the internal APIs, so it would be good to come back later and do a cleanup to remove this internal adjustment. Reviewers: pete, chandlerc Subscribers: javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D32819 llvm-svn: 303654
2017-05-24 01:01:48 +08:00
CurBuilder.merge(List.getAttributes(I - 1));
NewAttrSets[I] = AttributeSet::get(C, CurBuilder);
Remove some introspection functions. The 'getSlot' function and its ilk allow introspection into the AttributeSet class. However, that class should be opaque. Allow access through accessor methods instead. llvm-svn: 173522
2013-01-26 07:09:36 +08:00
}
[IR] Switch AttributeList to use an array for O(1) access Summary: Before this change, AttributeLists stored a pair of index and AttributeSet. This is memory efficient if most arguments do not have attributes. However, it requires doing a search over the pairs to test an argument or function attribute. Profiling shows that this loop was 0.76% of the time in 'opt -O2' of sqlite3.c, because LLVM constantly tests values for nullability. This was worth about 2.5% of mid-level optimization cycles on the sqlite3 amalgamation. Here are the full perf results: https://reviews.llvm.org/P7995 Here are just the before and after cycle counts: ``` $ perf stat -r 5 ./opt_before -O2 sqlite3.bc -o /dev/null 13,274,181,184 cycles # 3.047 GHz ( +- 0.28% ) $ perf stat -r 5 ./opt_after -O2 sqlite3.bc -o /dev/null 12,906,927,263 cycles # 3.043 GHz ( +- 0.51% ) ``` This patch *does not* change the indices used to query attributes, as requested by reviewers. Tracking whether an index is usable for array indexing is a huge pain that affects many of the internal APIs, so it would be good to come back later and do a cleanup to remove this internal adjustment. Reviewers: pete, chandlerc Subscribers: javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D32819 llvm-svn: 303654
2017-05-24 01:01:48 +08:00
return getImpl(C, NewAttrSets);
Split param attr implementation out from Function.cpp into its own file. Don't #include ParameterAttributes.h into any major public header files: just move methods out of line as appropriate. llvm-svn: 45517
2008-01-03 07:42:30 +08:00
}
Rename AttributeSet to AttributeList Summary: This class is a list of AttributeSetNodes corresponding the function prototype of a call or function declaration. This class used to be called ParamAttrListPtr, then AttrListPtr, then AttributeSet. It is typically accessed by parameter and return value index, so "AttributeList" seems like a more intuitive name. Rename AttributeSetImpl to AttributeListImpl to follow suit. It's useful to rename this class so that we can rename AttributeSetNode to AttributeSet later. AttributeSet is the set of attributes that apply to a single function, argument, or return value. Reviewers: sanjoy, javed.absar, chandlerc, pete Reviewed By: pete Subscribers: pete, jholewinski, arsenm, dschuff, mehdi_amini, jfb, nhaehnle, sbc100, void, llvm-commits Differential Revision: https://reviews.llvm.org/D31102 llvm-svn: 298393
2017-03-22 00:57:19 +08:00
AttributeList AttributeList::addAttribute(LLVMContext &C, unsigned Index,
Attribute::AttrKind Kind) const {
Make sure attribute kind and attributes are named respectively Kind and Attr consistently. Historically they used to be the same the terminology is very confused in the codebase. NFC. llvm-svn: 272704
2016-06-15 04:27:35 +08:00
if (hasAttribute(Index, Kind)) return *this;
[IR] Optimize adding attribute to AttributeList (NFC) When adding an enum attribute to an AttributeList, avoid going through an AttrBuilder and instead directly add the attribute to the correct set. Going through AttrBuilder is expensive, because it requires all string attributes to be reconstructed. This can be further improved by inserting the attribute at the right position and using the AttributeSetNode::getSorted() API. This recovers the small compile-time regression from D94633.
2021-01-22 17:38:36 +08:00
AttributeSet Attrs = getAttributes(Index);
// TODO: Insert at correct position and avoid sort.
SmallVector<Attribute, 8> NewAttrs(Attrs.begin(), Attrs.end());
NewAttrs.push_back(Attribute::get(C, Kind));
return setAttributes(C, Index, AttributeSet::get(C, NewAttrs));
Add some additonal attribute helper functions. Test will be on follow up putback to clang for mips16. llvm-svn: 176968
2013-03-14 04:20:08 +08:00
}
Rename AttributeSet to AttributeList Summary: This class is a list of AttributeSetNodes corresponding the function prototype of a call or function declaration. This class used to be called ParamAttrListPtr, then AttrListPtr, then AttributeSet. It is typically accessed by parameter and return value index, so "AttributeList" seems like a more intuitive name. Rename AttributeSetImpl to AttributeListImpl to follow suit. It's useful to rename this class so that we can rename AttributeSetNode to AttributeSet later. AttributeSet is the set of attributes that apply to a single function, argument, or return value. Reviewers: sanjoy, javed.absar, chandlerc, pete Reviewed By: pete Subscribers: pete, jholewinski, arsenm, dschuff, mehdi_amini, jfb, nhaehnle, sbc100, void, llvm-commits Differential Revision: https://reviews.llvm.org/D31102 llvm-svn: 298393
2017-03-22 00:57:19 +08:00
AttributeList AttributeList::addAttribute(LLVMContext &C, unsigned Index,
StringRef Kind,
StringRef Value) const {
[IR] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC). llvm-svn: 295383
2017-02-17 08:00:09 +08:00
AttrBuilder B;
Add a way to add a kind-value string pair to an attribute. llvm-svn: 187138
2013-07-26 02:34:24 +08:00
B.addAttribute(Kind, Value);
Re-land r301697 "[IR] Make add/remove Attributes use AttrBuilder instead of AttributeList" This time, I fixed, built, and tested clang. This reverts r301712. llvm-svn: 301981
2017-05-03 06:07:37 +08:00
return addAttributes(C, Index, B);
Add a way to add a kind-value string pair to an attribute. llvm-svn: 187138
2013-07-26 02:34:24 +08:00
}
[IR] Add additional addParamAttr/removeParamAttr to AttributeList API Summary: Fairly straightforward patch to fill in some of the holes in the attributes API with respect to accessing parameter/argument attributes. The patch aims to step further towards encapsulating the idx+FirstArgIndex pattern to access these attributes to within the AttributeList. Patch by Daniel Neilson! Reviewers: rnk, chandlerc, pete, javed.absar, reames Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D33355 llvm-svn: 304329
2017-06-01 03:23:09 +08:00
AttributeList AttributeList::addAttribute(LLVMContext &C, unsigned Index,
Rename AttributeSet to AttributeList Summary: This class is a list of AttributeSetNodes corresponding the function prototype of a call or function declaration. This class used to be called ParamAttrListPtr, then AttrListPtr, then AttributeSet. It is typically accessed by parameter and return value index, so "AttributeList" seems like a more intuitive name. Rename AttributeSetImpl to AttributeListImpl to follow suit. It's useful to rename this class so that we can rename AttributeSetNode to AttributeSet later. AttributeSet is the set of attributes that apply to a single function, argument, or return value. Reviewers: sanjoy, javed.absar, chandlerc, pete Reviewed By: pete Subscribers: pete, jholewinski, arsenm, dschuff, mehdi_amini, jfb, nhaehnle, sbc100, void, llvm-commits Differential Revision: https://reviews.llvm.org/D31102 llvm-svn: 298393
2017-03-22 00:57:19 +08:00
Attribute A) const {
[IR] Add additional addParamAttr/removeParamAttr to AttributeList API Summary: Fairly straightforward patch to fill in some of the holes in the attributes API with respect to accessing parameter/argument attributes. The patch aims to step further towards encapsulating the idx+FirstArgIndex pattern to access these attributes to within the AttributeList. Patch by Daniel Neilson! Reviewers: rnk, chandlerc, pete, javed.absar, reames Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D33355 llvm-svn: 304329
2017-06-01 03:23:09 +08:00
AttrBuilder B;
B.addAttribute(A);
return addAttributes(C, Index, B);
[AttributeSet] Overload AttributeSet::addAttribute to reduce compile time. The new overloaded function is used when an attribute is added to a large number of slots of an AttributeSet (for example, to function parameters). This is much faster than calling AttributeSet::addAttribute once per slot, because AttributeSet::getImpl (which calls FoldingSet::FIndNodeOrInsertPos) is called only once per function instead of once per slot. With this commit, clang compiles a file which used to take over 22 minutes in just 13 seconds. rdar://problem/23581000 Differential Revision: http://reviews.llvm.org/D15085 llvm-svn: 254491
2015-12-02 14:58:49 +08:00
}
[IR] Optimize adding attribute to AttributeList (NFC) When adding an enum attribute to an AttributeList, avoid going through an AttrBuilder and instead directly add the attribute to the correct set. Going through AttrBuilder is expensive, because it requires all string attributes to be reconstructed. This can be further improved by inserting the attribute at the right position and using the AttributeSetNode::getSorted() API. This recovers the small compile-time regression from D94633.
2021-01-22 17:38:36 +08:00
AttributeList AttributeList::setAttributes(LLVMContext &C, unsigned Index,
AttributeSet Attrs) const {
Index = attrIdxToArrayIdx(Index);
SmallVector<AttributeSet, 4> AttrSets(this->begin(), this->end());
if (Index >= AttrSets.size())
AttrSets.resize(Index + 1);
AttrSets[Index] = Attrs;
return AttributeList::getImpl(C, AttrSets);
}
Reland "[IR] Make AttributeSetNode public, avoid temporary AttributeList copies" This re-lands r299875. I introduced a bug in Clang code responsible for replacing K&R, no prototype declarations with a real function definition with a prototype. The bug was here: // Collect any return attributes from the call. - if (oldAttrs.hasAttributes(llvm::AttributeList::ReturnIndex)) - newAttrs.push_back(llvm::AttributeList::get(newFn->getContext(), - oldAttrs.getRetAttributes())); + newAttrs.push_back(oldAttrs.getRetAttributes()); Previously getRetAttributes() carried AttributeList::ReturnIndex in its AttributeList. Now that we return the AttributeSetNode* directly, it no longer carries that index, and we call this overload with a single node: AttributeList::get(LLVMContext&, ArrayRef<AttributeSetNode*>) That aborted with an assertion on x86_32 targets. I added an explicit triple to the test and added CHECKs to help find issues like this in the future sooner. llvm-svn: 299899
2017-04-11 07:31:05 +08:00
AttributeList AttributeList::addAttributes(LLVMContext &C, unsigned Index,
Remove buggy 'addAttributes(unsigned, AttrBuilder)' overload The 'addAttributes(unsigned, AttrBuilder)' overload delegated to 'get' instead of 'addAttributes'. Since we can implicitly construct an AttrBuilder from an AttributeSet, just standardize on AttrBuilder. llvm-svn: 300651
2017-04-19 09:51:13 +08:00
const AttrBuilder &B) const {
if (!B.hasAttributes())
Reland "[IR] Make AttributeSetNode public, avoid temporary AttributeList copies" This re-lands r299875. I introduced a bug in Clang code responsible for replacing K&R, no prototype declarations with a real function definition with a prototype. The bug was here: // Collect any return attributes from the call. - if (oldAttrs.hasAttributes(llvm::AttributeList::ReturnIndex)) - newAttrs.push_back(llvm::AttributeList::get(newFn->getContext(), - oldAttrs.getRetAttributes())); + newAttrs.push_back(oldAttrs.getRetAttributes()); Previously getRetAttributes() carried AttributeList::ReturnIndex in its AttributeList. Now that we return the AttributeSetNode* directly, it no longer carries that index, and we call this overload with a single node: AttributeList::get(LLVMContext&, ArrayRef<AttributeSetNode*>) That aborted with an assertion on x86_32 targets. I added an explicit triple to the test and added CHECKs to help find issues like this in the future sooner. llvm-svn: 299899
2017-04-11 07:31:05 +08:00
return *this;
Fix crash in AttributeList::addAttributes, add test llvm-svn: 300614
2017-04-19 06:10:18 +08:00
if (!pImpl)
Remove buggy 'addAttributes(unsigned, AttrBuilder)' overload The 'addAttributes(unsigned, AttrBuilder)' overload delegated to 'get' instead of 'addAttributes'. Since we can implicitly construct an AttrBuilder from an AttributeSet, just standardize on AttrBuilder. llvm-svn: 300651
2017-04-19 09:51:13 +08:00
return AttributeList::get(C, {{Index, AttributeSet::get(C, B)}});
Fix crash in AttributeList::addAttributes, add test llvm-svn: 300614
2017-04-19 06:10:18 +08:00
Add Alignment field to ParameterAttributes and treat more or less rationally in interface functions, subject to change. No functional change. llvm-svn: 47352
2008-02-20 07:51:49 +08:00
#ifndef NDEBUG
Rewrite the addAttr() method. This now uses the AttributeSet object instead of the Attribute / AttributeWithIndex objects. It's fairly simple now. It goes through all of the subsets before the one we're modifying, adds them to the new set. It then adds the modified subset. And then adds the rest of the subsets. llvm-svn: 173659
2013-01-28 13:23:28 +08:00
// FIXME it is not obvious how this should work for alignment. For now, say
// we can't change a known alignment.
[Alignment][NFC] Attributes use Align/MaybeAlign Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Subscribers: jholewinski, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69278 llvm-svn: 375495
2019-10-22 17:51:06 +08:00
const MaybeAlign OldAlign = getAttributes(Index).getAlignment();
[Alignment][NFC] Use MaybeAlign in AttrBuilder Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69300 llvm-svn: 375496
2019-10-22 19:57:52 +08:00
const MaybeAlign NewAlign = B.getAlignment();
Fix newly-introduced 4.3 warnings llvm-svn: 47375
2008-02-20 20:07:57 +08:00
assert((!OldAlign || !NewAlign || OldAlign == NewAlign) &&
Add Alignment field to ParameterAttributes and treat more or less rationally in interface functions, subject to change. No functional change. llvm-svn: 47352
2008-02-20 07:51:49 +08:00
"Attempt to change alignment!");
#endif
Cleanup whitespace. llvm-svn: 166013
2012-10-16 14:01:44 +08:00
[IR] Optimize adding attribute to AttributeList (NFC) When adding an enum attribute to an AttributeList, avoid going through an AttrBuilder and instead directly add the attribute to the correct set. Going through AttrBuilder is expensive, because it requires all string attributes to be reconstructed. This can be further improved by inserting the attribute at the right position and using the AttributeSetNode::getSorted() API. This recovers the small compile-time regression from D94633.
2021-01-22 17:38:36 +08:00
AttrBuilder Merged(getAttributes(Index));
[IR] Switch AttributeList to use an array for O(1) access Summary: Before this change, AttributeLists stored a pair of index and AttributeSet. This is memory efficient if most arguments do not have attributes. However, it requires doing a search over the pairs to test an argument or function attribute. Profiling shows that this loop was 0.76% of the time in 'opt -O2' of sqlite3.c, because LLVM constantly tests values for nullability. This was worth about 2.5% of mid-level optimization cycles on the sqlite3 amalgamation. Here are the full perf results: https://reviews.llvm.org/P7995 Here are just the before and after cycle counts: ``` $ perf stat -r 5 ./opt_before -O2 sqlite3.bc -o /dev/null 13,274,181,184 cycles # 3.047 GHz ( +- 0.28% ) $ perf stat -r 5 ./opt_after -O2 sqlite3.bc -o /dev/null 12,906,927,263 cycles # 3.043 GHz ( +- 0.51% ) ``` This patch *does not* change the indices used to query attributes, as requested by reviewers. Tracking whether an index is usable for array indexing is a huge pain that affects many of the internal APIs, so it would be good to come back later and do a cleanup to remove this internal adjustment. Reviewers: pete, chandlerc Subscribers: javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D32819 llvm-svn: 303654
2017-05-24 01:01:48 +08:00
Merged.merge(B);
[IR] Optimize adding attribute to AttributeList (NFC) When adding an enum attribute to an AttributeList, avoid going through an AttrBuilder and instead directly add the attribute to the correct set. Going through AttrBuilder is expensive, because it requires all string attributes to be reconstructed. This can be further improved by inserting the attribute at the right position and using the AttributeSetNode::getSorted() API. This recovers the small compile-time regression from D94633.
2021-01-22 17:38:36 +08:00
return setAttributes(C, Index, AttributeSet::get(C, Merged));
Reland "[IR] Make AttributeSetNode public, avoid temporary AttributeList copies" This re-lands r299875. I introduced a bug in Clang code responsible for replacing K&R, no prototype declarations with a real function definition with a prototype. The bug was here: // Collect any return attributes from the call. - if (oldAttrs.hasAttributes(llvm::AttributeList::ReturnIndex)) - newAttrs.push_back(llvm::AttributeList::get(newFn->getContext(), - oldAttrs.getRetAttributes())); + newAttrs.push_back(oldAttrs.getRetAttributes()); Previously getRetAttributes() carried AttributeList::ReturnIndex in its AttributeList. Now that we return the AttributeSetNode* directly, it no longer carries that index, and we call this overload with a single node: AttributeList::get(LLVMContext&, ArrayRef<AttributeSetNode*>) That aborted with an assertion on x86_32 targets. I added an explicit triple to the test and added CHECKs to help find issues like this in the future sooner. llvm-svn: 299899
2017-04-11 07:31:05 +08:00
}
[IR] Add additional addParamAttr/removeParamAttr to AttributeList API Summary: Fairly straightforward patch to fill in some of the holes in the attributes API with respect to accessing parameter/argument attributes. The patch aims to step further towards encapsulating the idx+FirstArgIndex pattern to access these attributes to within the AttributeList. Patch by Daniel Neilson! Reviewers: rnk, chandlerc, pete, javed.absar, reames Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D33355 llvm-svn: 304329
2017-06-01 03:23:09 +08:00
AttributeList AttributeList::addParamAttribute(LLVMContext &C,
ArrayRef<unsigned> ArgNos,
Attribute A) const {
[ADT/STLExtras.h] - Add llvm::is_sorted wrapper and update callers. It can be used to avoid passing the begin and end of a range. This makes the code shorter and it is consistent with another wrappers we already have. Differential revision: https://reviews.llvm.org/D78016
2020-04-13 19:46:41 +08:00
assert(llvm::is_sorted(ArgNos));
[IR] Add additional addParamAttr/removeParamAttr to AttributeList API Summary: Fairly straightforward patch to fill in some of the holes in the attributes API with respect to accessing parameter/argument attributes. The patch aims to step further towards encapsulating the idx+FirstArgIndex pattern to access these attributes to within the AttributeList. Patch by Daniel Neilson! Reviewers: rnk, chandlerc, pete, javed.absar, reames Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D33355 llvm-svn: 304329
2017-06-01 03:23:09 +08:00
SmallVector<AttributeSet, 4> AttrSets(this->begin(), this->end());
unsigned MaxIndex = attrIdxToArrayIdx(ArgNos.back() + FirstArgIndex);
if (MaxIndex >= AttrSets.size())
AttrSets.resize(MaxIndex + 1);
for (unsigned ArgNo : ArgNos) {
unsigned Index = attrIdxToArrayIdx(ArgNo + FirstArgIndex);
AttrBuilder B(AttrSets[Index]);
B.addAttribute(A);
AttrSets[Index] = AttributeSet::get(C, B);
}
return getImpl(C, AttrSets);
}
Rename AttributeSet to AttributeList Summary: This class is a list of AttributeSetNodes corresponding the function prototype of a call or function declaration. This class used to be called ParamAttrListPtr, then AttrListPtr, then AttributeSet. It is typically accessed by parameter and return value index, so "AttributeList" seems like a more intuitive name. Rename AttributeSetImpl to AttributeListImpl to follow suit. It's useful to rename this class so that we can rename AttributeSetNode to AttributeSet later. AttributeSet is the set of attributes that apply to a single function, argument, or return value. Reviewers: sanjoy, javed.absar, chandlerc, pete Reviewed By: pete Subscribers: pete, jholewinski, arsenm, dschuff, mehdi_amini, jfb, nhaehnle, sbc100, void, llvm-commits Differential Revision: https://reviews.llvm.org/D31102 llvm-svn: 298393
2017-03-22 00:57:19 +08:00
AttributeList AttributeList::removeAttribute(LLVMContext &C, unsigned Index,
Attribute::AttrKind Kind) const {
Make sure attribute kind and attributes are named respectively Kind and Attr consistently. Historically they used to be the same the terminology is very confused in the codebase. NFC. llvm-svn: 272704
2016-06-15 04:27:35 +08:00
if (!hasAttribute(Index, Kind)) return *this;
[Attributes] Fix crash when attempting to remove alignment from an attribute list/set Summary: Discovered while working on a patch to move alignment in @llvm.memcpy/move/set from an arg into parameter attributes. The current implementations of AttributeSet::removeAttribute() and AttributeList::removeAttribute crash when attempting to remove the alignment attribute. Currently, these implementations add the to-be-removed attributes to an AttrBuilder and then remove the builder from the list/set. Alignment is special in that it must be added to a builder with an integer value for the alignment; attempts to add alignment to a builder without a value is an error. This change fixes the removeAttribute implementations for AttributeSet and AttributeList to make them able to remove the alignment, and other similar, attributes. Reviewers: rnk, chandlerc, pete, javed.absar, reames Reviewed By: rnk Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D41951 llvm-svn: 322735
2018-01-18 03:15:21 +08:00
Index = attrIdxToArrayIdx(Index);
SmallVector<AttributeSet, 4> AttrSets(this->begin(), this->end());
assert(Index < AttrSets.size());
AttrSets[Index] = AttrSets[Index].removeAttribute(C, Kind);
return getImpl(C, AttrSets);
Use the AttributeSet when removing multiple attributes. Use Attribute::AttrKind when removing one attribute. This further encapsulates the use of the attributes. llvm-svn: 173214
2013-01-23 08:45:55 +08:00
}
Rename AttributeSet to AttributeList Summary: This class is a list of AttributeSetNodes corresponding the function prototype of a call or function declaration. This class used to be called ParamAttrListPtr, then AttrListPtr, then AttributeSet. It is typically accessed by parameter and return value index, so "AttributeList" seems like a more intuitive name. Rename AttributeSetImpl to AttributeListImpl to follow suit. It's useful to rename this class so that we can rename AttributeSetNode to AttributeSet later. AttributeSet is the set of attributes that apply to a single function, argument, or return value. Reviewers: sanjoy, javed.absar, chandlerc, pete Reviewed By: pete Subscribers: pete, jholewinski, arsenm, dschuff, mehdi_amini, jfb, nhaehnle, sbc100, void, llvm-commits Differential Revision: https://reviews.llvm.org/D31102 llvm-svn: 298393
2017-03-22 00:57:19 +08:00
AttributeList AttributeList::removeAttribute(LLVMContext &C, unsigned Index,
StringRef Kind) const {
Add support for string attributes in the C API. Summary: As per title. This completes the C API Attribute support. Reviewers: Wallbraker, whitequark, echristo, rafael, jyknight Subscribers: mehdi_amini Differential Revision: http://reviews.llvm.org/D21365 llvm-svn: 272811
2016-06-16 01:50:39 +08:00
if (!hasAttribute(Index, Kind)) return *this;
[Attributes] Fix crash when attempting to remove alignment from an attribute list/set Summary: Discovered while working on a patch to move alignment in @llvm.memcpy/move/set from an arg into parameter attributes. The current implementations of AttributeSet::removeAttribute() and AttributeList::removeAttribute crash when attempting to remove the alignment attribute. Currently, these implementations add the to-be-removed attributes to an AttrBuilder and then remove the builder from the list/set. Alignment is special in that it must be added to a builder with an integer value for the alignment; attempts to add alignment to a builder without a value is an error. This change fixes the removeAttribute implementations for AttributeSet and AttributeList to make them able to remove the alignment, and other similar, attributes. Reviewers: rnk, chandlerc, pete, javed.absar, reames Reviewed By: rnk Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D41951 llvm-svn: 322735
2018-01-18 03:15:21 +08:00
Index = attrIdxToArrayIdx(Index);
SmallVector<AttributeSet, 4> AttrSets(this->begin(), this->end());
assert(Index < AttrSets.size());
AttrSets[Index] = AttrSets[Index].removeAttribute(C, Kind);
return getImpl(C, AttrSets);
Split param attr implementation out from Function.cpp into its own file. Don't #include ParameterAttributes.h into any major public header files: just move methods out of line as appropriate. llvm-svn: 45517
2008-01-03 07:42:30 +08:00
}
[IR] Switch AttributeList to use an array for O(1) access Summary: Before this change, AttributeLists stored a pair of index and AttributeSet. This is memory efficient if most arguments do not have attributes. However, it requires doing a search over the pairs to test an argument or function attribute. Profiling shows that this loop was 0.76% of the time in 'opt -O2' of sqlite3.c, because LLVM constantly tests values for nullability. This was worth about 2.5% of mid-level optimization cycles on the sqlite3 amalgamation. Here are the full perf results: https://reviews.llvm.org/P7995 Here are just the before and after cycle counts: ``` $ perf stat -r 5 ./opt_before -O2 sqlite3.bc -o /dev/null 13,274,181,184 cycles # 3.047 GHz ( +- 0.28% ) $ perf stat -r 5 ./opt_after -O2 sqlite3.bc -o /dev/null 12,906,927,263 cycles # 3.043 GHz ( +- 0.51% ) ``` This patch *does not* change the indices used to query attributes, as requested by reviewers. Tracking whether an index is usable for array indexing is a huge pain that affects many of the internal APIs, so it would be good to come back later and do a cleanup to remove this internal adjustment. Reviewers: pete, chandlerc Subscribers: javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D32819 llvm-svn: 303654
2017-05-24 01:01:48 +08:00
AttributeList
AttributeList::removeAttributes(LLVMContext &C, unsigned Index,
const AttrBuilder &AttrsToRemove) const {
Rename AttributeSet to AttributeList Summary: This class is a list of AttributeSetNodes corresponding the function prototype of a call or function declaration. This class used to be called ParamAttrListPtr, then AttrListPtr, then AttributeSet. It is typically accessed by parameter and return value index, so "AttributeList" seems like a more intuitive name. Rename AttributeSetImpl to AttributeListImpl to follow suit. It's useful to rename this class so that we can rename AttributeSetNode to AttributeSet later. AttributeSet is the set of attributes that apply to a single function, argument, or return value. Reviewers: sanjoy, javed.absar, chandlerc, pete Reviewed By: pete Subscribers: pete, jholewinski, arsenm, dschuff, mehdi_amini, jfb, nhaehnle, sbc100, void, llvm-commits Differential Revision: https://reviews.llvm.org/D31102 llvm-svn: 298393
2017-03-22 00:57:19 +08:00
if (!pImpl)
[IR] Fix some Clang-tidy modernize-use-auto warnings; other minor fixes (NFC). llvm-svn: 328850
2018-03-30 08:47:31 +08:00
return {};
Add remove method to operate on AttrBuilder instead of AttributeSet. Prior to this change we would have to construct a temporary AttributeSet (which isn't temporary at all given that its allocated on the context), just to contain the attributes in the builder, then call remove on that. Now we can just remove any attributes from the (lightweight and really temporary) builder itself. Will be used in a future commit to remove some temporary attributes sets. llvm-svn: 236666
2015-05-07 07:19:43 +08:00
[IR] Switch AttributeList to use an array for O(1) access Summary: Before this change, AttributeLists stored a pair of index and AttributeSet. This is memory efficient if most arguments do not have attributes. However, it requires doing a search over the pairs to test an argument or function attribute. Profiling shows that this loop was 0.76% of the time in 'opt -O2' of sqlite3.c, because LLVM constantly tests values for nullability. This was worth about 2.5% of mid-level optimization cycles on the sqlite3 amalgamation. Here are the full perf results: https://reviews.llvm.org/P7995 Here are just the before and after cycle counts: ``` $ perf stat -r 5 ./opt_before -O2 sqlite3.bc -o /dev/null 13,274,181,184 cycles # 3.047 GHz ( +- 0.28% ) $ perf stat -r 5 ./opt_after -O2 sqlite3.bc -o /dev/null 12,906,927,263 cycles # 3.043 GHz ( +- 0.51% ) ``` This patch *does not* change the indices used to query attributes, as requested by reviewers. Tracking whether an index is usable for array indexing is a huge pain that affects many of the internal APIs, so it would be good to come back later and do a cleanup to remove this internal adjustment. Reviewers: pete, chandlerc Subscribers: javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D32819 llvm-svn: 303654
2017-05-24 01:01:48 +08:00
Index = attrIdxToArrayIdx(Index);
SmallVector<AttributeSet, 4> AttrSets(this->begin(), this->end());
if (Index >= AttrSets.size())
AttrSets.resize(Index + 1);
Add remove method to operate on AttrBuilder instead of AttributeSet. Prior to this change we would have to construct a temporary AttributeSet (which isn't temporary at all given that its allocated on the context), just to contain the attributes in the builder, then call remove on that. Now we can just remove any attributes from the (lightweight and really temporary) builder itself. Will be used in a future commit to remove some temporary attributes sets. llvm-svn: 236666
2015-05-07 07:19:43 +08:00
[Attributes] Fix crash when attempting to remove alignment from an attribute list/set Summary: Discovered while working on a patch to move alignment in @llvm.memcpy/move/set from an arg into parameter attributes. The current implementations of AttributeSet::removeAttribute() and AttributeList::removeAttribute crash when attempting to remove the alignment attribute. Currently, these implementations add the to-be-removed attributes to an AttrBuilder and then remove the builder from the list/set. Alignment is special in that it must be added to a builder with an integer value for the alignment; attempts to add alignment to a builder without a value is an error. This change fixes the removeAttribute implementations for AttributeSet and AttributeList to make them able to remove the alignment, and other similar, attributes. Reviewers: rnk, chandlerc, pete, javed.absar, reames Reviewed By: rnk Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D41951 llvm-svn: 322735
2018-01-18 03:15:21 +08:00
AttrSets[Index] = AttrSets[Index].removeAttributes(C, AttrsToRemove);
Add remove method to operate on AttrBuilder instead of AttributeSet. Prior to this change we would have to construct a temporary AttributeSet (which isn't temporary at all given that its allocated on the context), just to contain the attributes in the builder, then call remove on that. Now we can just remove any attributes from the (lightweight and really temporary) builder itself. Will be used in a future commit to remove some temporary attributes sets. llvm-svn: 236666
2015-05-07 07:19:43 +08:00
[IR] Switch AttributeList to use an array for O(1) access Summary: Before this change, AttributeLists stored a pair of index and AttributeSet. This is memory efficient if most arguments do not have attributes. However, it requires doing a search over the pairs to test an argument or function attribute. Profiling shows that this loop was 0.76% of the time in 'opt -O2' of sqlite3.c, because LLVM constantly tests values for nullability. This was worth about 2.5% of mid-level optimization cycles on the sqlite3 amalgamation. Here are the full perf results: https://reviews.llvm.org/P7995 Here are just the before and after cycle counts: ``` $ perf stat -r 5 ./opt_before -O2 sqlite3.bc -o /dev/null 13,274,181,184 cycles # 3.047 GHz ( +- 0.28% ) $ perf stat -r 5 ./opt_after -O2 sqlite3.bc -o /dev/null 12,906,927,263 cycles # 3.043 GHz ( +- 0.51% ) ``` This patch *does not* change the indices used to query attributes, as requested by reviewers. Tracking whether an index is usable for array indexing is a huge pain that affects many of the internal APIs, so it would be good to come back later and do a cleanup to remove this internal adjustment. Reviewers: pete, chandlerc Subscribers: javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D32819 llvm-svn: 303654
2017-05-24 01:01:48 +08:00
return getImpl(C, AttrSets);
Add remove method to operate on AttrBuilder instead of AttributeSet. Prior to this change we would have to construct a temporary AttributeSet (which isn't temporary at all given that its allocated on the context), just to contain the attributes in the builder, then call remove on that. Now we can just remove any attributes from the (lightweight and really temporary) builder itself. Will be used in a future commit to remove some temporary attributes sets. llvm-svn: 236666
2015-05-07 07:19:43 +08:00
}
Reland "[IR] Make AttributeSetNode public, avoid temporary AttributeList copies" This re-lands r299875. I introduced a bug in Clang code responsible for replacing K&R, no prototype declarations with a real function definition with a prototype. The bug was here: // Collect any return attributes from the call. - if (oldAttrs.hasAttributes(llvm::AttributeList::ReturnIndex)) - newAttrs.push_back(llvm::AttributeList::get(newFn->getContext(), - oldAttrs.getRetAttributes())); + newAttrs.push_back(oldAttrs.getRetAttributes()); Previously getRetAttributes() carried AttributeList::ReturnIndex in its AttributeList. Now that we return the AttributeSetNode* directly, it no longer carries that index, and we call this overload with a single node: AttributeList::get(LLVMContext&, ArrayRef<AttributeSetNode*>) That aborted with an assertion on x86_32 targets. I added an explicit triple to the test and added CHECKs to help find issues like this in the future sooner. llvm-svn: 299899
2017-04-11 07:31:05 +08:00
AttributeList AttributeList::removeAttributes(LLVMContext &C,
unsigned WithoutIndex) const {
if (!pImpl)
[IR] Fix some Clang-tidy modernize-use-auto warnings; other minor fixes (NFC). llvm-svn: 328850
2018-03-30 08:47:31 +08:00
return {};
[IR] Switch AttributeList to use an array for O(1) access Summary: Before this change, AttributeLists stored a pair of index and AttributeSet. This is memory efficient if most arguments do not have attributes. However, it requires doing a search over the pairs to test an argument or function attribute. Profiling shows that this loop was 0.76% of the time in 'opt -O2' of sqlite3.c, because LLVM constantly tests values for nullability. This was worth about 2.5% of mid-level optimization cycles on the sqlite3 amalgamation. Here are the full perf results: https://reviews.llvm.org/P7995 Here are just the before and after cycle counts: ``` $ perf stat -r 5 ./opt_before -O2 sqlite3.bc -o /dev/null 13,274,181,184 cycles # 3.047 GHz ( +- 0.28% ) $ perf stat -r 5 ./opt_after -O2 sqlite3.bc -o /dev/null 12,906,927,263 cycles # 3.043 GHz ( +- 0.51% ) ``` This patch *does not* change the indices used to query attributes, as requested by reviewers. Tracking whether an index is usable for array indexing is a huge pain that affects many of the internal APIs, so it would be good to come back later and do a cleanup to remove this internal adjustment. Reviewers: pete, chandlerc Subscribers: javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D32819 llvm-svn: 303654
2017-05-24 01:01:48 +08:00
WithoutIndex = attrIdxToArrayIdx(WithoutIndex);
if (WithoutIndex >= getNumAttrSets())
return *this;
SmallVector<AttributeSet, 4> AttrSets(this->begin(), this->end());
AttrSets[WithoutIndex] = AttributeSet();
return getImpl(C, AttrSets);
Reland "[IR] Make AttributeSetNode public, avoid temporary AttributeList copies" This re-lands r299875. I introduced a bug in Clang code responsible for replacing K&R, no prototype declarations with a real function definition with a prototype. The bug was here: // Collect any return attributes from the call. - if (oldAttrs.hasAttributes(llvm::AttributeList::ReturnIndex)) - newAttrs.push_back(llvm::AttributeList::get(newFn->getContext(), - oldAttrs.getRetAttributes())); + newAttrs.push_back(oldAttrs.getRetAttributes()); Previously getRetAttributes() carried AttributeList::ReturnIndex in its AttributeList. Now that we return the AttributeSetNode* directly, it no longer carries that index, and we call this overload with a single node: AttributeList::get(LLVMContext&, ArrayRef<AttributeSetNode*>) That aborted with an assertion on x86_32 targets. I added an explicit triple to the test and added CHECKs to help find issues like this in the future sooner. llvm-svn: 299899
2017-04-11 07:31:05 +08:00
}
Rename AttributeSet to AttributeList Summary: This class is a list of AttributeSetNodes corresponding the function prototype of a call or function declaration. This class used to be called ParamAttrListPtr, then AttrListPtr, then AttributeSet. It is typically accessed by parameter and return value index, so "AttributeList" seems like a more intuitive name. Rename AttributeSetImpl to AttributeListImpl to follow suit. It's useful to rename this class so that we can rename AttributeSetNode to AttributeSet later. AttributeSet is the set of attributes that apply to a single function, argument, or return value. Reviewers: sanjoy, javed.absar, chandlerc, pete Reviewed By: pete Subscribers: pete, jholewinski, arsenm, dschuff, mehdi_amini, jfb, nhaehnle, sbc100, void, llvm-commits Differential Revision: https://reviews.llvm.org/D31102 llvm-svn: 298393
2017-03-22 00:57:19 +08:00
AttributeList AttributeList::addDereferenceableAttr(LLVMContext &C,
unsigned Index,
uint64_t Bytes) const {
[IR] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC). llvm-svn: 295383
2017-02-17 08:00:09 +08:00
AttrBuilder B;
InstCombine: propagate deref via new addDereferenceableAttr The "dereferenceable" attribute cannot be added via .addAttribute(), since it also expects a size in bytes. AttrBuilder#addAttribute or AttributeSet#addAttribute is wrapped by classes Function, InvokeInst, and CallInst. Add corresponding wrappers to AttrBuilder#addDereferenceableAttr. Having done this, propagate the dereferenceable attribute via gc.relocate, adding a test to exercise it. Note that -datalayout is required during execution over and above -instcombine, because InstCombine only optionally requires DataLayoutPass. Differential Revision: http://reviews.llvm.org/D7510 llvm-svn: 229265
2015-02-15 03:37:54 +08:00
B.addDereferenceableAttr(Bytes);
Re-land r301697 "[IR] Make add/remove Attributes use AttrBuilder instead of AttributeList" This time, I fixed, built, and tested clang. This reverts r301712. llvm-svn: 301981
2017-05-03 06:07:37 +08:00
return addAttributes(C, Index, B);
InstCombine: propagate deref via new addDereferenceableAttr The "dereferenceable" attribute cannot be added via .addAttribute(), since it also expects a size in bytes. AttrBuilder#addAttribute or AttributeSet#addAttribute is wrapped by classes Function, InvokeInst, and CallInst. Add corresponding wrappers to AttrBuilder#addDereferenceableAttr. Having done this, propagate the dereferenceable attribute via gc.relocate, adding a test to exercise it. Note that -datalayout is required during execution over and above -instcombine, because InstCombine only optionally requires DataLayoutPass. Differential Revision: http://reviews.llvm.org/D7510 llvm-svn: 229265
2015-02-15 03:37:54 +08:00
}
Rename AttributeSet to AttributeList Summary: This class is a list of AttributeSetNodes corresponding the function prototype of a call or function declaration. This class used to be called ParamAttrListPtr, then AttrListPtr, then AttributeSet. It is typically accessed by parameter and return value index, so "AttributeList" seems like a more intuitive name. Rename AttributeSetImpl to AttributeListImpl to follow suit. It's useful to rename this class so that we can rename AttributeSetNode to AttributeSet later. AttributeSet is the set of attributes that apply to a single function, argument, or return value. Reviewers: sanjoy, javed.absar, chandlerc, pete Reviewed By: pete Subscribers: pete, jholewinski, arsenm, dschuff, mehdi_amini, jfb, nhaehnle, sbc100, void, llvm-commits Differential Revision: https://reviews.llvm.org/D31102 llvm-svn: 298393
2017-03-22 00:57:19 +08:00
AttributeList
AttributeList::addDereferenceableOrNullAttr(LLVMContext &C, unsigned Index,
uint64_t Bytes) const {
[IR] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC). llvm-svn: 295383
2017-02-17 08:00:09 +08:00
AttrBuilder B;
[IR] Introduce a dereferenceable_or_null(N) attribute. Summary: If a pointer is marked as dereferenceable_or_null(N), LLVM assumes it is either `null` or `dereferenceable(N)` or both. This change only introduces the attribute and adds a token test case for the `llvm-as` / `llvm-dis`. It does not hook up other parts of the optimizer to actually exploit the attribute -- those changes will come later. For pointers in address space 0, `dereferenceable(N)` is now exactly equivalent to `dereferenceable_or_null(N)` && `nonnull`. For other address spaces, `dereferenceable(N)` is potentially weaker than `dereferenceable_or_null(N)` && `nonnull` (since we could have a null `dereferenceable(N)` pointer). The motivating case for this change is Java (and other managed languages), where pointers are either `null` or dereferenceable up to some usually known-at-compile-time constant offset. Reviewers: rafael, hfinkel Reviewed By: hfinkel Subscribers: nicholas, llvm-commits Differential Revision: http://reviews.llvm.org/D8650 llvm-svn: 235132
2015-04-17 04:29:50 +08:00
B.addDereferenceableOrNullAttr(Bytes);
Re-land r301697 "[IR] Make add/remove Attributes use AttrBuilder instead of AttributeList" This time, I fixed, built, and tested clang. This reverts r301712. llvm-svn: 301981
2017-05-03 06:07:37 +08:00
return addAttributes(C, Index, B);
[IR] Introduce a dereferenceable_or_null(N) attribute. Summary: If a pointer is marked as dereferenceable_or_null(N), LLVM assumes it is either `null` or `dereferenceable(N)` or both. This change only introduces the attribute and adds a token test case for the `llvm-as` / `llvm-dis`. It does not hook up other parts of the optimizer to actually exploit the attribute -- those changes will come later. For pointers in address space 0, `dereferenceable(N)` is now exactly equivalent to `dereferenceable_or_null(N)` && `nonnull`. For other address spaces, `dereferenceable(N)` is potentially weaker than `dereferenceable_or_null(N)` && `nonnull` (since we could have a null `dereferenceable(N)` pointer). The motivating case for this change is Java (and other managed languages), where pointers are either `null` or dereferenceable up to some usually known-at-compile-time constant offset. Reviewers: rafael, hfinkel Reviewed By: hfinkel Subscribers: nicholas, llvm-commits Differential Revision: http://reviews.llvm.org/D8650 llvm-svn: 235132
2015-04-17 04:29:50 +08:00
}
Rename AttributeSet to AttributeList Summary: This class is a list of AttributeSetNodes corresponding the function prototype of a call or function declaration. This class used to be called ParamAttrListPtr, then AttrListPtr, then AttributeSet. It is typically accessed by parameter and return value index, so "AttributeList" seems like a more intuitive name. Rename AttributeSetImpl to AttributeListImpl to follow suit. It's useful to rename this class so that we can rename AttributeSetNode to AttributeSet later. AttributeSet is the set of attributes that apply to a single function, argument, or return value. Reviewers: sanjoy, javed.absar, chandlerc, pete Reviewed By: pete Subscribers: pete, jholewinski, arsenm, dschuff, mehdi_amini, jfb, nhaehnle, sbc100, void, llvm-commits Differential Revision: https://reviews.llvm.org/D31102 llvm-svn: 298393
2017-03-22 00:57:19 +08:00
AttributeList
AttributeList::addAllocSizeAttr(LLVMContext &C, unsigned Index,
unsigned ElemSizeArg,
const Optional<unsigned> &NumElemsArg) {
[IR] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC). llvm-svn: 295383
2017-02-17 08:00:09 +08:00
AttrBuilder B;
Add the allocsize attribute to LLVM. `allocsize` is a function attribute that allows users to request that LLVM treat arbitrary functions as allocation functions. This patch makes LLVM accept the `allocsize` attribute, and makes `@llvm.objectsize` recognize said attribute. The review for this was split into two patches for ease of reviewing: D18974 and D14933. As promised on the revisions, I'm landing both patches as a single commit. Differential Revision: http://reviews.llvm.org/D14933 llvm-svn: 266032
2016-04-12 09:05:35 +08:00
B.addAllocSizeAttr(ElemSizeArg, NumElemsArg);
Re-land r301697 "[IR] Make add/remove Attributes use AttrBuilder instead of AttributeList" This time, I fixed, built, and tested clang. This reverts r301712. llvm-svn: 301981
2017-05-03 06:07:37 +08:00
return addAttributes(C, Index, B);
Add the allocsize attribute to LLVM. `allocsize` is a function attribute that allows users to request that LLVM treat arbitrary functions as allocation functions. This patch makes LLVM accept the `allocsize` attribute, and makes `@llvm.objectsize` recognize said attribute. The review for this was split into two patches for ease of reviewing: D18974 and D14933. As promised on the revisions, I'm landing both patches as a single commit. Differential Revision: http://reviews.llvm.org/D14933 llvm-svn: 266032
2016-04-12 09:05:35 +08:00
}
Reorder some functions and add comments. No functionality change. llvm-svn: 173733
2013-01-29 08:34:06 +08:00
//===----------------------------------------------------------------------===//
Rename AttributeSet to AttributeList Summary: This class is a list of AttributeSetNodes corresponding the function prototype of a call or function declaration. This class used to be called ParamAttrListPtr, then AttrListPtr, then AttributeSet. It is typically accessed by parameter and return value index, so "AttributeList" seems like a more intuitive name. Rename AttributeSetImpl to AttributeListImpl to follow suit. It's useful to rename this class so that we can rename AttributeSetNode to AttributeSet later. AttributeSet is the set of attributes that apply to a single function, argument, or return value. Reviewers: sanjoy, javed.absar, chandlerc, pete Reviewed By: pete Subscribers: pete, jholewinski, arsenm, dschuff, mehdi_amini, jfb, nhaehnle, sbc100, void, llvm-commits Differential Revision: https://reviews.llvm.org/D31102 llvm-svn: 298393
2017-03-22 00:57:19 +08:00
// AttributeList Accessor Methods
Reorder some functions and add comments. No functionality change. llvm-svn: 173733
2013-01-29 08:34:06 +08:00
//===----------------------------------------------------------------------===//
[IR] Make getParamAttributes take argument numbers, not ArgNo+1 Add hasParamAttribute() and use it instead of hasAttribute(ArgNo+1, Kind) everywhere. The fact that the AttributeList index for an argument is ArgNo+1 should be a hidden implementation detail. NFC llvm-svn: 300272
2017-04-14 07:12:13 +08:00
AttributeSet AttributeList::getParamAttributes(unsigned ArgNo) const {
[IR] Abstract away ArgNo+1 attribute indexing as much as possible Summary: Do three things to help with that: - Add AttributeList::FirstArgIndex, which is an enumerator currently set to 1. It allows us to change the indexing scheme with fewer changes. - Add addParamAttr/removeParamAttr. This just shortens addAttribute call sites that would otherwise need to spell out FirstArgIndex. - Remove some attribute-specific getters and setters from Function that take attribute list indices. Most of these were only used from BuildLibCalls, and doesNotAlias was only used to test or set if the return value is malloc-like. I'm happy to split the patch, but I think they are probably easier to review when taken together. This patch should be NFC, but it sets the stage to change the indexing scheme to this, which is more convenient when indexing into an array: 0: func attrs 1: retattrs 2...: arg attrs Reviewers: chandlerc, pete, javed.absar Subscribers: david2050, llvm-commits Differential Revision: https://reviews.llvm.org/D32811 llvm-svn: 302060
2017-05-04 02:17:31 +08:00
return getAttributes(ArgNo + FirstArgIndex);
Reorder some functions and add comments. No functionality change. llvm-svn: 173733
2013-01-29 08:34:06 +08:00
}
[IR] Add AttributeSet to hide AttributeSetNode* again, NFC Summary: For now, it just wraps AttributeSetNode*. Eventually, it will hold AvailableAttrs as an inline bitset, and adding and removing enum attributes will be super cheap. This sinks AttributeSetNode back down to lib/IR/AttributeImpl.h. Reviewers: pete, chandlerc Subscribers: llvm-commits, jfb Differential Revision: https://reviews.llvm.org/D31940 llvm-svn: 300014
2017-04-12 08:38:00 +08:00
AttributeSet AttributeList::getRetAttributes() const {
Reland "[IR] Make AttributeSetNode public, avoid temporary AttributeList copies" This re-lands r299875. I introduced a bug in Clang code responsible for replacing K&R, no prototype declarations with a real function definition with a prototype. The bug was here: // Collect any return attributes from the call. - if (oldAttrs.hasAttributes(llvm::AttributeList::ReturnIndex)) - newAttrs.push_back(llvm::AttributeList::get(newFn->getContext(), - oldAttrs.getRetAttributes())); + newAttrs.push_back(oldAttrs.getRetAttributes()); Previously getRetAttributes() carried AttributeList::ReturnIndex in its AttributeList. Now that we return the AttributeSetNode* directly, it no longer carries that index, and we call this overload with a single node: AttributeList::get(LLVMContext&, ArrayRef<AttributeSetNode*>) That aborted with an assertion on x86_32 targets. I added an explicit triple to the test and added CHECKs to help find issues like this in the future sooner. llvm-svn: 299899
2017-04-11 07:31:05 +08:00
return getAttributes(ReturnIndex);
Reorder some functions and add comments. No functionality change. llvm-svn: 173733
2013-01-29 08:34:06 +08:00
}
[IR] Add AttributeSet to hide AttributeSetNode* again, NFC Summary: For now, it just wraps AttributeSetNode*. Eventually, it will hold AvailableAttrs as an inline bitset, and adding and removing enum attributes will be super cheap. This sinks AttributeSetNode back down to lib/IR/AttributeImpl.h. Reviewers: pete, chandlerc Subscribers: llvm-commits, jfb Differential Revision: https://reviews.llvm.org/D31940 llvm-svn: 300014
2017-04-12 08:38:00 +08:00
AttributeSet AttributeList::getFnAttributes() const {
Reland "[IR] Make AttributeSetNode public, avoid temporary AttributeList copies" This re-lands r299875. I introduced a bug in Clang code responsible for replacing K&R, no prototype declarations with a real function definition with a prototype. The bug was here: // Collect any return attributes from the call. - if (oldAttrs.hasAttributes(llvm::AttributeList::ReturnIndex)) - newAttrs.push_back(llvm::AttributeList::get(newFn->getContext(), - oldAttrs.getRetAttributes())); + newAttrs.push_back(oldAttrs.getRetAttributes()); Previously getRetAttributes() carried AttributeList::ReturnIndex in its AttributeList. Now that we return the AttributeSetNode* directly, it no longer carries that index, and we call this overload with a single node: AttributeList::get(LLVMContext&, ArrayRef<AttributeSetNode*>) That aborted with an assertion on x86_32 targets. I added an explicit triple to the test and added CHECKs to help find issues like this in the future sooner. llvm-svn: 299899
2017-04-11 07:31:05 +08:00
return getAttributes(FunctionIndex);
Reorder some functions and add comments. No functionality change. llvm-svn: 173733
2013-01-29 08:34:06 +08:00
}
Rename AttributeSet to AttributeList Summary: This class is a list of AttributeSetNodes corresponding the function prototype of a call or function declaration. This class used to be called ParamAttrListPtr, then AttrListPtr, then AttributeSet. It is typically accessed by parameter and return value index, so "AttributeList" seems like a more intuitive name. Rename AttributeSetImpl to AttributeListImpl to follow suit. It's useful to rename this class so that we can rename AttributeSetNode to AttributeSet later. AttributeSet is the set of attributes that apply to a single function, argument, or return value. Reviewers: sanjoy, javed.absar, chandlerc, pete Reviewed By: pete Subscribers: pete, jholewinski, arsenm, dschuff, mehdi_amini, jfb, nhaehnle, sbc100, void, llvm-commits Differential Revision: https://reviews.llvm.org/D31102 llvm-svn: 298393
2017-03-22 00:57:19 +08:00
bool AttributeList::hasAttribute(unsigned Index,
Attribute::AttrKind Kind) const {
[IR] Add AttributeSet to hide AttributeSetNode* again, NFC Summary: For now, it just wraps AttributeSetNode*. Eventually, it will hold AvailableAttrs as an inline bitset, and adding and removing enum attributes will be super cheap. This sinks AttributeSetNode back down to lib/IR/AttributeImpl.h. Reviewers: pete, chandlerc Subscribers: llvm-commits, jfb Differential Revision: https://reviews.llvm.org/D31940 llvm-svn: 300014
2017-04-12 08:38:00 +08:00
return getAttributes(Index).hasAttribute(Kind);
Reorder some functions and add comments. No functionality change. llvm-svn: 173733
2013-01-29 08:34:06 +08:00
}
Rename AttributeSet to AttributeList Summary: This class is a list of AttributeSetNodes corresponding the function prototype of a call or function declaration. This class used to be called ParamAttrListPtr, then AttrListPtr, then AttributeSet. It is typically accessed by parameter and return value index, so "AttributeList" seems like a more intuitive name. Rename AttributeSetImpl to AttributeListImpl to follow suit. It's useful to rename this class so that we can rename AttributeSetNode to AttributeSet later. AttributeSet is the set of attributes that apply to a single function, argument, or return value. Reviewers: sanjoy, javed.absar, chandlerc, pete Reviewed By: pete Subscribers: pete, jholewinski, arsenm, dschuff, mehdi_amini, jfb, nhaehnle, sbc100, void, llvm-commits Differential Revision: https://reviews.llvm.org/D31102 llvm-svn: 298393
2017-03-22 00:57:19 +08:00
bool AttributeList::hasAttribute(unsigned Index, StringRef Kind) const {
[IR] Add AttributeSet to hide AttributeSetNode* again, NFC Summary: For now, it just wraps AttributeSetNode*. Eventually, it will hold AvailableAttrs as an inline bitset, and adding and removing enum attributes will be super cheap. This sinks AttributeSetNode back down to lib/IR/AttributeImpl.h. Reviewers: pete, chandlerc Subscribers: llvm-commits, jfb Differential Revision: https://reviews.llvm.org/D31940 llvm-svn: 300014
2017-04-12 08:38:00 +08:00
return getAttributes(Index).hasAttribute(Kind);
Add some accessor and query methods for retrieving Attribute objects and such. llvm-svn: 175046
2013-02-13 16:42:21 +08:00
}
Rename AttributeSet to AttributeList Summary: This class is a list of AttributeSetNodes corresponding the function prototype of a call or function declaration. This class used to be called ParamAttrListPtr, then AttrListPtr, then AttributeSet. It is typically accessed by parameter and return value index, so "AttributeList" seems like a more intuitive name. Rename AttributeSetImpl to AttributeListImpl to follow suit. It's useful to rename this class so that we can rename AttributeSetNode to AttributeSet later. AttributeSet is the set of attributes that apply to a single function, argument, or return value. Reviewers: sanjoy, javed.absar, chandlerc, pete Reviewed By: pete Subscribers: pete, jholewinski, arsenm, dschuff, mehdi_amini, jfb, nhaehnle, sbc100, void, llvm-commits Differential Revision: https://reviews.llvm.org/D31102 llvm-svn: 298393
2017-03-22 00:57:19 +08:00
bool AttributeList::hasAttributes(unsigned Index) const {
[IR] Add AttributeSet to hide AttributeSetNode* again, NFC Summary: For now, it just wraps AttributeSetNode*. Eventually, it will hold AvailableAttrs as an inline bitset, and adding and removing enum attributes will be super cheap. This sinks AttributeSetNode back down to lib/IR/AttributeImpl.h. Reviewers: pete, chandlerc Subscribers: llvm-commits, jfb Differential Revision: https://reviews.llvm.org/D31940 llvm-svn: 300014
2017-04-12 08:38:00 +08:00
return getAttributes(Index).hasAttributes();
Reorder some functions and add comments. No functionality change. llvm-svn: 173733
2013-01-29 08:34:06 +08:00
}
Rename AttributeSet to AttributeList Summary: This class is a list of AttributeSetNodes corresponding the function prototype of a call or function declaration. This class used to be called ParamAttrListPtr, then AttrListPtr, then AttributeSet. It is typically accessed by parameter and return value index, so "AttributeList" seems like a more intuitive name. Rename AttributeSetImpl to AttributeListImpl to follow suit. It's useful to rename this class so that we can rename AttributeSetNode to AttributeSet later. AttributeSet is the set of attributes that apply to a single function, argument, or return value. Reviewers: sanjoy, javed.absar, chandlerc, pete Reviewed By: pete Subscribers: pete, jholewinski, arsenm, dschuff, mehdi_amini, jfb, nhaehnle, sbc100, void, llvm-commits Differential Revision: https://reviews.llvm.org/D31102 llvm-svn: 298393
2017-03-22 00:57:19 +08:00
bool AttributeList::hasFnAttribute(Attribute::AttrKind Kind) const {
AttributeSetImpl: Summarize existing function attributes in a bitset. The majority of attribute queries checks for the existence of an enum attribute in the FunctionIndex slot. We only have 48 of those and can therefore summarize them in an uint64_t bitset which measurably improves compile time. Differential Revision: http://reviews.llvm.org/D16618 llvm-svn: 259252
2016-01-30 06:25:19 +08:00
return pImpl && pImpl->hasFnAttribute(Kind);
}
Rename AttributeSet to AttributeList Summary: This class is a list of AttributeSetNodes corresponding the function prototype of a call or function declaration. This class used to be called ParamAttrListPtr, then AttrListPtr, then AttributeSet. It is typically accessed by parameter and return value index, so "AttributeList" seems like a more intuitive name. Rename AttributeSetImpl to AttributeListImpl to follow suit. It's useful to rename this class so that we can rename AttributeSetNode to AttributeSet later. AttributeSet is the set of attributes that apply to a single function, argument, or return value. Reviewers: sanjoy, javed.absar, chandlerc, pete Reviewed By: pete Subscribers: pete, jholewinski, arsenm, dschuff, mehdi_amini, jfb, nhaehnle, sbc100, void, llvm-commits Differential Revision: https://reviews.llvm.org/D31102 llvm-svn: 298393
2017-03-22 00:57:19 +08:00
bool AttributeList::hasFnAttribute(StringRef Kind) const {
return hasAttribute(AttributeList::FunctionIndex, Kind);
Rationalise the attribute getter/setter methods on Function and CallSite. Summary: While woring on mapping attributes in the C API, it clearly appeared that the recent changes in the API on the C++ side left Function and Call/Invoke with an attribute API that grew in an ad hoc manner. This makes it difficult to work with it, because one doesn't know which overloads exists and which do not. Make sure that getter/setter function exists for both enum and string version. Remove inconsistent getter/setter, unless they have many callsites. This should make it easier to work with attributes in the future. This doesn't change how attribute works. Reviewers: bkramer, whitequark, mehdi_amini, void Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D21514 llvm-svn: 281019
2016-09-09 12:50:38 +08:00
}
[IR] Make getParamAttributes take argument numbers, not ArgNo+1 Add hasParamAttribute() and use it instead of hasAttribute(ArgNo+1, Kind) everywhere. The fact that the AttributeList index for an argument is ArgNo+1 should be a hidden implementation detail. NFC llvm-svn: 300272
2017-04-14 07:12:13 +08:00
bool AttributeList::hasParamAttribute(unsigned ArgNo,
Attribute::AttrKind Kind) const {
[IR] Switch AttributeList to use an array for O(1) access Summary: Before this change, AttributeLists stored a pair of index and AttributeSet. This is memory efficient if most arguments do not have attributes. However, it requires doing a search over the pairs to test an argument or function attribute. Profiling shows that this loop was 0.76% of the time in 'opt -O2' of sqlite3.c, because LLVM constantly tests values for nullability. This was worth about 2.5% of mid-level optimization cycles on the sqlite3 amalgamation. Here are the full perf results: https://reviews.llvm.org/P7995 Here are just the before and after cycle counts: ``` $ perf stat -r 5 ./opt_before -O2 sqlite3.bc -o /dev/null 13,274,181,184 cycles # 3.047 GHz ( +- 0.28% ) $ perf stat -r 5 ./opt_after -O2 sqlite3.bc -o /dev/null 12,906,927,263 cycles # 3.043 GHz ( +- 0.51% ) ``` This patch *does not* change the indices used to query attributes, as requested by reviewers. Tracking whether an index is usable for array indexing is a huge pain that affects many of the internal APIs, so it would be good to come back later and do a cleanup to remove this internal adjustment. Reviewers: pete, chandlerc Subscribers: javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D32819 llvm-svn: 303654
2017-05-24 01:01:48 +08:00
return hasAttribute(ArgNo + FirstArgIndex, Kind);
[IR] Make getParamAttributes take argument numbers, not ArgNo+1 Add hasParamAttribute() and use it instead of hasAttribute(ArgNo+1, Kind) everywhere. The fact that the AttributeList index for an argument is ArgNo+1 should be a hidden implementation detail. NFC llvm-svn: 300272
2017-04-14 07:12:13 +08:00
}
Rename AttributeSet to AttributeList Summary: This class is a list of AttributeSetNodes corresponding the function prototype of a call or function declaration. This class used to be called ParamAttrListPtr, then AttrListPtr, then AttributeSet. It is typically accessed by parameter and return value index, so "AttributeList" seems like a more intuitive name. Rename AttributeSetImpl to AttributeListImpl to follow suit. It's useful to rename this class so that we can rename AttributeSetNode to AttributeSet later. AttributeSet is the set of attributes that apply to a single function, argument, or return value. Reviewers: sanjoy, javed.absar, chandlerc, pete Reviewed By: pete Subscribers: pete, jholewinski, arsenm, dschuff, mehdi_amini, jfb, nhaehnle, sbc100, void, llvm-commits Differential Revision: https://reviews.llvm.org/D31102 llvm-svn: 298393
2017-03-22 00:57:19 +08:00
bool AttributeList::hasAttrSomewhere(Attribute::AttrKind Attr,
unsigned *Index) const {
[IR] Store attributes that are available "somewhere" (NFC) I noticed that for some benchmarks we spend quite a bit of time inside AttributeList::hasAttrSomewhere(), mainly when checking for the "returned" attribute. Most of the time the attribute will not be present, in which case this function has to walk through the whole attribute list and check for the attribute at each index. This patch adds a cache of all "available somewhere" attributes inside AttributeListImpl. This makes the structure 12 bytes larger, but I don't think that's problematic, as attribute lists are uniqued. Compile-time in terms of instructions retired improves by 0.4% on average, but >1% for sqlite. Differential Revision: https://reviews.llvm.org/D81867
2020-06-15 04:49:57 +08:00
return pImpl && pImpl->hasAttrSomewhere(Attr, Index);
Reorder some functions and add comments. No functionality change. llvm-svn: 173733
2013-01-29 08:34:06 +08:00
}
Rename AttributeSet to AttributeList Summary: This class is a list of AttributeSetNodes corresponding the function prototype of a call or function declaration. This class used to be called ParamAttrListPtr, then AttrListPtr, then AttributeSet. It is typically accessed by parameter and return value index, so "AttributeList" seems like a more intuitive name. Rename AttributeSetImpl to AttributeListImpl to follow suit. It's useful to rename this class so that we can rename AttributeSetNode to AttributeSet later. AttributeSet is the set of attributes that apply to a single function, argument, or return value. Reviewers: sanjoy, javed.absar, chandlerc, pete Reviewed By: pete Subscribers: pete, jholewinski, arsenm, dschuff, mehdi_amini, jfb, nhaehnle, sbc100, void, llvm-commits Differential Revision: https://reviews.llvm.org/D31102 llvm-svn: 298393
2017-03-22 00:57:19 +08:00
Attribute AttributeList::getAttribute(unsigned Index,
Attribute::AttrKind Kind) const {
[IR] Add AttributeSet to hide AttributeSetNode* again, NFC Summary: For now, it just wraps AttributeSetNode*. Eventually, it will hold AvailableAttrs as an inline bitset, and adding and removing enum attributes will be super cheap. This sinks AttributeSetNode back down to lib/IR/AttributeImpl.h. Reviewers: pete, chandlerc Subscribers: llvm-commits, jfb Differential Revision: https://reviews.llvm.org/D31940 llvm-svn: 300014
2017-04-12 08:38:00 +08:00
return getAttributes(Index).getAttribute(Kind);
Add some accessor and query methods for retrieving Attribute objects and such. llvm-svn: 175046
2013-02-13 16:42:21 +08:00
}
Rename AttributeSet to AttributeList Summary: This class is a list of AttributeSetNodes corresponding the function prototype of a call or function declaration. This class used to be called ParamAttrListPtr, then AttrListPtr, then AttributeSet. It is typically accessed by parameter and return value index, so "AttributeList" seems like a more intuitive name. Rename AttributeSetImpl to AttributeListImpl to follow suit. It's useful to rename this class so that we can rename AttributeSetNode to AttributeSet later. AttributeSet is the set of attributes that apply to a single function, argument, or return value. Reviewers: sanjoy, javed.absar, chandlerc, pete Reviewed By: pete Subscribers: pete, jholewinski, arsenm, dschuff, mehdi_amini, jfb, nhaehnle, sbc100, void, llvm-commits Differential Revision: https://reviews.llvm.org/D31102 llvm-svn: 298393
2017-03-22 00:57:19 +08:00
Attribute AttributeList::getAttribute(unsigned Index, StringRef Kind) const {
[IR] Add AttributeSet to hide AttributeSetNode* again, NFC Summary: For now, it just wraps AttributeSetNode*. Eventually, it will hold AvailableAttrs as an inline bitset, and adding and removing enum attributes will be super cheap. This sinks AttributeSetNode back down to lib/IR/AttributeImpl.h. Reviewers: pete, chandlerc Subscribers: llvm-commits, jfb Differential Revision: https://reviews.llvm.org/D31940 llvm-svn: 300014
2017-04-12 08:38:00 +08:00
return getAttributes(Index).getAttribute(Kind);
Add some accessor and query methods for retrieving Attribute objects and such. llvm-svn: 175046
2013-02-13 16:42:21 +08:00
}
[Alignment][NFC] Attributes use Align/MaybeAlign Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Subscribers: jholewinski, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69278 llvm-svn: 375495
2019-10-22 17:51:06 +08:00
MaybeAlign AttributeList::getRetAlignment() const {
Make getParamAlignment use argument numbers The method is called "get *Param* Alignment", and is only used for return values exactly once, so it should take argument indices, not attribute indices. Avoids confusing code like: IsSwiftError = CS->paramHasAttr(ArgIdx, Attribute::SwiftError); Alignment = CS->getParamAlignment(ArgIdx + 1); Add getRetAlignment to handle the one case in Value.cpp that wants the return value alignment. This is a potentially breaking change for out-of-tree backends that do their own call lowering. llvm-svn: 301682
2017-04-29 04:34:27 +08:00
return getAttributes(ReturnIndex).getAlignment();
}
[Alignment][NFC] Attributes use Align/MaybeAlign Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Subscribers: jholewinski, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69278 llvm-svn: 375495
2019-10-22 17:51:06 +08:00
MaybeAlign AttributeList::getParamAlignment(unsigned ArgNo) const {
[IR] Abstract away ArgNo+1 attribute indexing as much as possible Summary: Do three things to help with that: - Add AttributeList::FirstArgIndex, which is an enumerator currently set to 1. It allows us to change the indexing scheme with fewer changes. - Add addParamAttr/removeParamAttr. This just shortens addAttribute call sites that would otherwise need to spell out FirstArgIndex. - Remove some attribute-specific getters and setters from Function that take attribute list indices. Most of these were only used from BuildLibCalls, and doesNotAlias was only used to test or set if the return value is malloc-like. I'm happy to split the patch, but I think they are probably easier to review when taken together. This patch should be NFC, but it sets the stage to change the indexing scheme to this, which is more convenient when indexing into an array: 0: func attrs 1: retattrs 2...: arg attrs Reviewers: chandlerc, pete, javed.absar Subscribers: david2050, llvm-commits Differential Revision: https://reviews.llvm.org/D32811 llvm-svn: 302060
2017-05-04 02:17:31 +08:00
return getAttributes(ArgNo + FirstArgIndex).getAlignment();
Reorder some functions and add comments. No functionality change. llvm-svn: 173733
2013-01-29 08:34:06 +08:00
}
Reapply: IR: add optional type to 'byval' function parameters When we switch to opaque pointer types we will need some way to describe how many bytes a 'byval' parameter should occupy on the stack. This adds a (for now) optional extra type parameter. If present, the type must match the pointee type of the argument. The original commit did not remap byval types when linking modules, which broke LTO. This version fixes that. Note to front-end maintainers: if this causes test failures, it's probably because the "byval" attribute is printed after attributes without any parameter after this change. llvm-svn: 362128
2019-05-31 02:48:23 +08:00
Type *AttributeList::getParamByValType(unsigned Index) const {
return getAttributes(Index+FirstArgIndex).getByValType();
}
Reapply "OpaquePtr: Add type to sret attribute" This reverts commit eb9f7c28e5fe6d75fed3587023e17f2997c8024b. Previously this was incorrectly handling linking of the contained type, so this merges the fixes from D88973.
2020-09-29 21:33:55 +08:00
Type *AttributeList::getParamStructRetType(unsigned Index) const {
return getAttributes(Index + FirstArgIndex).getStructRetType();
}
IR: Define byref parameter attribute This allows tracking the in-memory type of a pointer argument to a function for ABI purposes. This is essentially a stripped down version of byval to remove some of the stack-copy implications in its definition. This includes the base IR changes, and some tests for places where it should be treated similarly to byval. Codegen support will be in a future patch. My original attempt at solving some of these problems was to repurpose byval with a different address space from the stack. However, it is technically permitted for the callee to introduce a write to the argument, although nothing does this in reality. There is also talk of removing and replacing the byval attribute, so a new attribute would need to take its place anyway. This is intended avoid some optimization issues with the current handling of aggregate arguments, as well as fixes inflexibilty in how frontends can specify the kernel ABI. The most honest representation of the amdgpu_kernel convention is to expose all kernel arguments as loads from constant memory. Today, these are raw, SSA Argument values and codegen is responsible for turning these into loads. Background: There currently isn't a satisfactory way to represent how arguments for the amdgpu_kernel calling convention are passed. In reality, arguments are passed in a single, flat, constant memory buffer implicitly passed to the function. It is also illegal to call this function in the IR, and this is only ever invoked by a driver of some kind. It does not make sense to have a stack passed parameter in this context as is implied by byval. It is never valid to write to the kernel arguments, as this would corrupt the inputs seen by other dispatches of the kernel. These argumets are also not in the same address space as the stack, so a copy is needed to an alloca. From a source C-like language, the kernel parameters are invisible. Semantically, a copy is always required from the constant argument memory to a mutable variable. The current clang calling convention lowering emits raw values, including aggregates into the function argument list, since using byval would not make sense. This has some unfortunate consequences for the optimizer. In the aggregate case, we end up with an aggregate store to alloca, which both SROA and instcombine turn into a store of each aggregate field. The optimizer never pieces this back together to see that this is really just a copy from constant memory, so we end up stuck with expensive stack usage. This also means the backend dictates the alignment of arguments, and arbitrarily picks the LLVM IR ABI type alignment. By allowing an explicit alignment, frontends can make better decisions. For example, there's real no advantage to an aligment higher than 4, so a frontend could choose to compact the argument layout. Similarly, there is a high penalty to using an alignment lower than 4, so a frontend could opt into more padding for small arguments. Another design consideration is when it is appropriate to expose the fact that these arguments are all really passed in adjacent memory. Currently we have a late IR optimization pass in codegen to rewrite the kernel argument values into explicit loads to enable vectorization. In most programs, unrelated argument loads can be merged together. However, exposing this property directly from the frontend has some disadvantages. We still need a way to track the original argument sizes and alignments to report to the driver. I find using some side-channel, metadata mechanism to track this unappealing. If the kernel arguments were exposed as a single buffer to begin with, alias analysis would be unaware that the padding bits betewen arguments are meaningless. Another family of problems is there are still some gaps in replacing all of the available parameter attributes with metadata equivalents once lowered to loads. The immediate plan is to start using this new attribute to handle all aggregate argumets for kernels. Long term, it makes sense to migrate all kernel arguments, including scalars, to be passed indirectly in the same manner. Additional context is in D79744.
2020-06-06 04:58:47 +08:00
Type *AttributeList::getParamByRefType(unsigned Index) const {
return getAttributes(Index + FirstArgIndex).getByRefType();
}
Reland [X86] Codegen for preallocated See https://reviews.llvm.org/D74651 for the preallocated IR constructs and LangRef changes. In X86TargetLowering::LowerCall(), if a call is preallocated, record each argument's offset from the stack pointer and the total stack adjustment. Associate the call Value with an integer index. Store the info in X86MachineFunctionInfo with the integer index as the key. This adds two new target independent ISDOpcodes and two new target dependent Opcodes corresponding to @llvm.call.preallocated.{setup,arg}. The setup ISelDAG node takes in a chain and outputs a chain and a SrcValue of the preallocated call Value. It is lowered to a target dependent node with the SrcValue replaced with the integer index key by looking in X86MachineFunctionInfo. In X86TargetLowering::EmitInstrWithCustomInserter() this is lowered to an %esp adjustment, the exact amount determined by looking in X86MachineFunctionInfo with the integer index key. The arg ISelDAG node takes in a chain, a SrcValue of the preallocated call Value, and the arg index int constant. It produces a chain and the pointer fo the arg. It is lowered to a target dependent node with the SrcValue replaced with the integer index key by looking in X86MachineFunctionInfo. In X86TargetLowering::EmitInstrWithCustomInserter() this is lowered to a lea of the stack pointer plus an offset determined by looking in X86MachineFunctionInfo with the integer index key. Force any function containing a preallocated call to use the frame pointer. Does not yet handle a setup without a call, or a conditional call. Does not yet handle musttail. That requires a LangRef change first. Tried to look at all references to inalloca and see if they apply to preallocated. I've made preallocated versions of tests testing inalloca whenever possible and when they make sense (e.g. not alloca related, inalloca edge cases). Aside from the tests added here, I checked that this codegen produces correct code for something like ``` struct A { A(); A(A&&); ~A(); }; void bar() { foo(foo(foo(foo(foo(A(), 4), 5), 6), 7), 8); } ``` by replacing the inalloca version of the .ll file with the appropriate preallocated code. Running the executable produces the same results as using the current inalloca implementation. Reverted due to unexpectedly passing tests, added REQUIRES: asserts for reland. Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D77689
2020-03-17 03:32:36 +08:00
Type *AttributeList::getParamPreallocatedType(unsigned Index) const {
return getAttributes(Index + FirstArgIndex).getPreallocatedType();
}
[Alignment][NFC] Attributes use Align/MaybeAlign Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Subscribers: jholewinski, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69278 llvm-svn: 375495
2019-10-22 17:51:06 +08:00
MaybeAlign AttributeList::getStackAlignment(unsigned Index) const {
[IR] Add AttributeSet to hide AttributeSetNode* again, NFC Summary: For now, it just wraps AttributeSetNode*. Eventually, it will hold AvailableAttrs as an inline bitset, and adding and removing enum attributes will be super cheap. This sinks AttributeSetNode back down to lib/IR/AttributeImpl.h. Reviewers: pete, chandlerc Subscribers: llvm-commits, jfb Differential Revision: https://reviews.llvm.org/D31940 llvm-svn: 300014
2017-04-12 08:38:00 +08:00
return getAttributes(Index).getStackAlignment();
Reorder some functions and add comments. No functionality change. llvm-svn: 173733
2013-01-29 08:34:06 +08:00
}
Rename AttributeSet to AttributeList Summary: This class is a list of AttributeSetNodes corresponding the function prototype of a call or function declaration. This class used to be called ParamAttrListPtr, then AttrListPtr, then AttributeSet. It is typically accessed by parameter and return value index, so "AttributeList" seems like a more intuitive name. Rename AttributeSetImpl to AttributeListImpl to follow suit. It's useful to rename this class so that we can rename AttributeSetNode to AttributeSet later. AttributeSet is the set of attributes that apply to a single function, argument, or return value. Reviewers: sanjoy, javed.absar, chandlerc, pete Reviewed By: pete Subscribers: pete, jholewinski, arsenm, dschuff, mehdi_amini, jfb, nhaehnle, sbc100, void, llvm-commits Differential Revision: https://reviews.llvm.org/D31102 llvm-svn: 298393
2017-03-22 00:57:19 +08:00
uint64_t AttributeList::getDereferenceableBytes(unsigned Index) const {
[IR] Add AttributeSet to hide AttributeSetNode* again, NFC Summary: For now, it just wraps AttributeSetNode*. Eventually, it will hold AvailableAttrs as an inline bitset, and adding and removing enum attributes will be super cheap. This sinks AttributeSetNode back down to lib/IR/AttributeImpl.h. Reviewers: pete, chandlerc Subscribers: llvm-commits, jfb Differential Revision: https://reviews.llvm.org/D31940 llvm-svn: 300014
2017-04-12 08:38:00 +08:00
return getAttributes(Index).getDereferenceableBytes();
Add a dereferenceable attribute This attribute indicates that the parameter or return pointer is dereferenceable. Practically speaking, loads from such a pointer within the associated byte range are safe to speculatively execute. Such pointer parameters are common in source languages (C++ references, for example). llvm-svn: 213385
2014-07-18 23:51:28 +08:00
}
Rename AttributeSet to AttributeList Summary: This class is a list of AttributeSetNodes corresponding the function prototype of a call or function declaration. This class used to be called ParamAttrListPtr, then AttrListPtr, then AttributeSet. It is typically accessed by parameter and return value index, so "AttributeList" seems like a more intuitive name. Rename AttributeSetImpl to AttributeListImpl to follow suit. It's useful to rename this class so that we can rename AttributeSetNode to AttributeSet later. AttributeSet is the set of attributes that apply to a single function, argument, or return value. Reviewers: sanjoy, javed.absar, chandlerc, pete Reviewed By: pete Subscribers: pete, jholewinski, arsenm, dschuff, mehdi_amini, jfb, nhaehnle, sbc100, void, llvm-commits Differential Revision: https://reviews.llvm.org/D31102 llvm-svn: 298393
2017-03-22 00:57:19 +08:00
uint64_t AttributeList::getDereferenceableOrNullBytes(unsigned Index) const {
[IR] Add AttributeSet to hide AttributeSetNode* again, NFC Summary: For now, it just wraps AttributeSetNode*. Eventually, it will hold AvailableAttrs as an inline bitset, and adding and removing enum attributes will be super cheap. This sinks AttributeSetNode back down to lib/IR/AttributeImpl.h. Reviewers: pete, chandlerc Subscribers: llvm-commits, jfb Differential Revision: https://reviews.llvm.org/D31940 llvm-svn: 300014
2017-04-12 08:38:00 +08:00
return getAttributes(Index).getDereferenceableOrNullBytes();
Add missing dereferenceable_or_null getters Summary: Add missing dereferenceable_or_null getters required for http://reviews.llvm.org/D9253 change. Separated from the D9253 review. Patch by Artur Pilipenko! Reviewers: sanjoy Reviewed By: sanjoy Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D9499 llvm-svn: 236615
2015-05-07 01:41:54 +08:00
}
Add the allocsize attribute to LLVM. `allocsize` is a function attribute that allows users to request that LLVM treat arbitrary functions as allocation functions. This patch makes LLVM accept the `allocsize` attribute, and makes `@llvm.objectsize` recognize said attribute. The review for this was split into two patches for ease of reviewing: D18974 and D14933. As promised on the revisions, I'm landing both patches as a single commit. Differential Revision: http://reviews.llvm.org/D14933 llvm-svn: 266032
2016-04-12 09:05:35 +08:00
std::pair<unsigned, Optional<unsigned>>
Rename AttributeSet to AttributeList Summary: This class is a list of AttributeSetNodes corresponding the function prototype of a call or function declaration. This class used to be called ParamAttrListPtr, then AttrListPtr, then AttributeSet. It is typically accessed by parameter and return value index, so "AttributeList" seems like a more intuitive name. Rename AttributeSetImpl to AttributeListImpl to follow suit. It's useful to rename this class so that we can rename AttributeSetNode to AttributeSet later. AttributeSet is the set of attributes that apply to a single function, argument, or return value. Reviewers: sanjoy, javed.absar, chandlerc, pete Reviewed By: pete Subscribers: pete, jholewinski, arsenm, dschuff, mehdi_amini, jfb, nhaehnle, sbc100, void, llvm-commits Differential Revision: https://reviews.llvm.org/D31102 llvm-svn: 298393
2017-03-22 00:57:19 +08:00
AttributeList::getAllocSizeArgs(unsigned Index) const {
[IR] Add AttributeSet to hide AttributeSetNode* again, NFC Summary: For now, it just wraps AttributeSetNode*. Eventually, it will hold AvailableAttrs as an inline bitset, and adding and removing enum attributes will be super cheap. This sinks AttributeSetNode back down to lib/IR/AttributeImpl.h. Reviewers: pete, chandlerc Subscribers: llvm-commits, jfb Differential Revision: https://reviews.llvm.org/D31940 llvm-svn: 300014
2017-04-12 08:38:00 +08:00
return getAttributes(Index).getAllocSizeArgs();
Add the allocsize attribute to LLVM. `allocsize` is a function attribute that allows users to request that LLVM treat arbitrary functions as allocation functions. This patch makes LLVM accept the `allocsize` attribute, and makes `@llvm.objectsize` recognize said attribute. The review for this was split into two patches for ease of reviewing: D18974 and D14933. As promised on the revisions, I'm landing both patches as a single commit. Differential Revision: http://reviews.llvm.org/D14933 llvm-svn: 266032
2016-04-12 09:05:35 +08:00
}
Rename AttributeSet to AttributeList Summary: This class is a list of AttributeSetNodes corresponding the function prototype of a call or function declaration. This class used to be called ParamAttrListPtr, then AttrListPtr, then AttributeSet. It is typically accessed by parameter and return value index, so "AttributeList" seems like a more intuitive name. Rename AttributeSetImpl to AttributeListImpl to follow suit. It's useful to rename this class so that we can rename AttributeSetNode to AttributeSet later. AttributeSet is the set of attributes that apply to a single function, argument, or return value. Reviewers: sanjoy, javed.absar, chandlerc, pete Reviewed By: pete Subscribers: pete, jholewinski, arsenm, dschuff, mehdi_amini, jfb, nhaehnle, sbc100, void, llvm-commits Differential Revision: https://reviews.llvm.org/D31102 llvm-svn: 298393
2017-03-22 00:57:19 +08:00
std::string AttributeList::getAsString(unsigned Index, bool InAttrGrp) const {
[IR] Add AttributeSet to hide AttributeSetNode* again, NFC Summary: For now, it just wraps AttributeSetNode*. Eventually, it will hold AvailableAttrs as an inline bitset, and adding and removing enum attributes will be super cheap. This sinks AttributeSetNode back down to lib/IR/AttributeImpl.h. Reviewers: pete, chandlerc Subscribers: llvm-commits, jfb Differential Revision: https://reviews.llvm.org/D31940 llvm-svn: 300014
2017-04-12 08:38:00 +08:00
return getAttributes(Index).getAsString(InAttrGrp);
Reorder some functions and add comments. No functionality change. llvm-svn: 173733
2013-01-29 08:34:06 +08:00
}
[IR] Add AttributeSet to hide AttributeSetNode* again, NFC Summary: For now, it just wraps AttributeSetNode*. Eventually, it will hold AvailableAttrs as an inline bitset, and adding and removing enum attributes will be super cheap. This sinks AttributeSetNode back down to lib/IR/AttributeImpl.h. Reviewers: pete, chandlerc Subscribers: llvm-commits, jfb Differential Revision: https://reviews.llvm.org/D31940 llvm-svn: 300014
2017-04-12 08:38:00 +08:00
AttributeSet AttributeList::getAttributes(unsigned Index) const {
[IR] Switch AttributeList to use an array for O(1) access Summary: Before this change, AttributeLists stored a pair of index and AttributeSet. This is memory efficient if most arguments do not have attributes. However, it requires doing a search over the pairs to test an argument or function attribute. Profiling shows that this loop was 0.76% of the time in 'opt -O2' of sqlite3.c, because LLVM constantly tests values for nullability. This was worth about 2.5% of mid-level optimization cycles on the sqlite3 amalgamation. Here are the full perf results: https://reviews.llvm.org/P7995 Here are just the before and after cycle counts: ``` $ perf stat -r 5 ./opt_before -O2 sqlite3.bc -o /dev/null 13,274,181,184 cycles # 3.047 GHz ( +- 0.28% ) $ perf stat -r 5 ./opt_after -O2 sqlite3.bc -o /dev/null 12,906,927,263 cycles # 3.043 GHz ( +- 0.51% ) ``` This patch *does not* change the indices used to query attributes, as requested by reviewers. Tracking whether an index is usable for array indexing is a huge pain that affects many of the internal APIs, so it would be good to come back later and do a cleanup to remove this internal adjustment. Reviewers: pete, chandlerc Subscribers: javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D32819 llvm-svn: 303654
2017-05-24 01:01:48 +08:00
Index = attrIdxToArrayIdx(Index);
if (!pImpl || Index >= getNumAttrSets())
[IR] Fix some Clang-tidy modernize-use-auto warnings; other minor fixes (NFC). llvm-svn: 328850
2018-03-30 08:47:31 +08:00
return {};
[IR] Switch AttributeList to use an array for O(1) access Summary: Before this change, AttributeLists stored a pair of index and AttributeSet. This is memory efficient if most arguments do not have attributes. However, it requires doing a search over the pairs to test an argument or function attribute. Profiling shows that this loop was 0.76% of the time in 'opt -O2' of sqlite3.c, because LLVM constantly tests values for nullability. This was worth about 2.5% of mid-level optimization cycles on the sqlite3 amalgamation. Here are the full perf results: https://reviews.llvm.org/P7995 Here are just the before and after cycle counts: ``` $ perf stat -r 5 ./opt_before -O2 sqlite3.bc -o /dev/null 13,274,181,184 cycles # 3.047 GHz ( +- 0.28% ) $ perf stat -r 5 ./opt_after -O2 sqlite3.bc -o /dev/null 12,906,927,263 cycles # 3.043 GHz ( +- 0.51% ) ``` This patch *does not* change the indices used to query attributes, as requested by reviewers. Tracking whether an index is usable for array indexing is a huge pain that affects many of the internal APIs, so it would be good to come back later and do a cleanup to remove this internal adjustment. Reviewers: pete, chandlerc Subscribers: javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D32819 llvm-svn: 303654
2017-05-24 01:01:48 +08:00
return pImpl->begin()[Index];
Reorder some functions and add comments. No functionality change. llvm-svn: 173733
2013-01-29 08:34:06 +08:00
}
[IR] Switch AttributeList to use an array for O(1) access Summary: Before this change, AttributeLists stored a pair of index and AttributeSet. This is memory efficient if most arguments do not have attributes. However, it requires doing a search over the pairs to test an argument or function attribute. Profiling shows that this loop was 0.76% of the time in 'opt -O2' of sqlite3.c, because LLVM constantly tests values for nullability. This was worth about 2.5% of mid-level optimization cycles on the sqlite3 amalgamation. Here are the full perf results: https://reviews.llvm.org/P7995 Here are just the before and after cycle counts: ``` $ perf stat -r 5 ./opt_before -O2 sqlite3.bc -o /dev/null 13,274,181,184 cycles # 3.047 GHz ( +- 0.28% ) $ perf stat -r 5 ./opt_after -O2 sqlite3.bc -o /dev/null 12,906,927,263 cycles # 3.043 GHz ( +- 0.51% ) ``` This patch *does not* change the indices used to query attributes, as requested by reviewers. Tracking whether an index is usable for array indexing is a huge pain that affects many of the internal APIs, so it would be good to come back later and do a cleanup to remove this internal adjustment. Reviewers: pete, chandlerc Subscribers: javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D32819 llvm-svn: 303654
2017-05-24 01:01:48 +08:00
AttributeList::iterator AttributeList::begin() const {
return pImpl ? pImpl->begin() : nullptr;
Add iterators to the AttributeSet class so that we can access the Attributes in a nice way. llvm-svn: 174120
2013-02-01 07:53:05 +08:00
}
[IR] Switch AttributeList to use an array for O(1) access Summary: Before this change, AttributeLists stored a pair of index and AttributeSet. This is memory efficient if most arguments do not have attributes. However, it requires doing a search over the pairs to test an argument or function attribute. Profiling shows that this loop was 0.76% of the time in 'opt -O2' of sqlite3.c, because LLVM constantly tests values for nullability. This was worth about 2.5% of mid-level optimization cycles on the sqlite3 amalgamation. Here are the full perf results: https://reviews.llvm.org/P7995 Here are just the before and after cycle counts: ``` $ perf stat -r 5 ./opt_before -O2 sqlite3.bc -o /dev/null 13,274,181,184 cycles # 3.047 GHz ( +- 0.28% ) $ perf stat -r 5 ./opt_after -O2 sqlite3.bc -o /dev/null 12,906,927,263 cycles # 3.043 GHz ( +- 0.51% ) ``` This patch *does not* change the indices used to query attributes, as requested by reviewers. Tracking whether an index is usable for array indexing is a huge pain that affects many of the internal APIs, so it would be good to come back later and do a cleanup to remove this internal adjustment. Reviewers: pete, chandlerc Subscribers: javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D32819 llvm-svn: 303654
2017-05-24 01:01:48 +08:00
AttributeList::iterator AttributeList::end() const {
return pImpl ? pImpl->end() : nullptr;
Add iterators to the AttributeSet class so that we can access the Attributes in a nice way. llvm-svn: 174120
2013-02-01 07:53:05 +08:00
}
Reorder some functions and add comments. No functionality change. llvm-svn: 173733
2013-01-29 08:34:06 +08:00
//===----------------------------------------------------------------------===//
Rename AttributeSet to AttributeList Summary: This class is a list of AttributeSetNodes corresponding the function prototype of a call or function declaration. This class used to be called ParamAttrListPtr, then AttrListPtr, then AttributeSet. It is typically accessed by parameter and return value index, so "AttributeList" seems like a more intuitive name. Rename AttributeSetImpl to AttributeListImpl to follow suit. It's useful to rename this class so that we can rename AttributeSetNode to AttributeSet later. AttributeSet is the set of attributes that apply to a single function, argument, or return value. Reviewers: sanjoy, javed.absar, chandlerc, pete Reviewed By: pete Subscribers: pete, jholewinski, arsenm, dschuff, mehdi_amini, jfb, nhaehnle, sbc100, void, llvm-commits Differential Revision: https://reviews.llvm.org/D31102 llvm-svn: 298393
2017-03-22 00:57:19 +08:00
// AttributeList Introspection Methods
Reorder some functions and add comments. No functionality change. llvm-svn: 173733
2013-01-29 08:34:06 +08:00
//===----------------------------------------------------------------------===//
[IR] Switch AttributeList to use an array for O(1) access Summary: Before this change, AttributeLists stored a pair of index and AttributeSet. This is memory efficient if most arguments do not have attributes. However, it requires doing a search over the pairs to test an argument or function attribute. Profiling shows that this loop was 0.76% of the time in 'opt -O2' of sqlite3.c, because LLVM constantly tests values for nullability. This was worth about 2.5% of mid-level optimization cycles on the sqlite3 amalgamation. Here are the full perf results: https://reviews.llvm.org/P7995 Here are just the before and after cycle counts: ``` $ perf stat -r 5 ./opt_before -O2 sqlite3.bc -o /dev/null 13,274,181,184 cycles # 3.047 GHz ( +- 0.28% ) $ perf stat -r 5 ./opt_after -O2 sqlite3.bc -o /dev/null 12,906,927,263 cycles # 3.043 GHz ( +- 0.51% ) ``` This patch *does not* change the indices used to query attributes, as requested by reviewers. Tracking whether an index is usable for array indexing is a huge pain that affects many of the internal APIs, so it would be good to come back later and do a cleanup to remove this internal adjustment. Reviewers: pete, chandlerc Subscribers: javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D32819 llvm-svn: 303654
2017-05-24 01:01:48 +08:00
unsigned AttributeList::getNumAttrSets() const {
return pImpl ? pImpl->NumAttrSets : 0;
Reorder some functions and add comments. No functionality change. llvm-svn: 173733
2013-01-29 08:34:06 +08:00
}
Reverting r315590; it did not include changes for llvm-tblgen, which is causing link errors for several people. Error LNK2019 unresolved external symbol "public: void __cdecl `anonymous namespace'::MatchableInfo::dump(void)const " (?dump@MatchableInfo@?A0xf4f1c304@@QEBAXXZ) referenced in function "public: void __cdecl `anonymous namespace'::AsmMatcherEmitter::run(class llvm::raw_ostream &)" (?run@AsmMatcherEmitter@?A0xf4f1c304@@QEAAXAEAVraw_ostream@llvm@@@Z) llvm-tblgen D:\llvm\2017\utils\TableGen\AsmMatcherEmitter.obj 1 llvm-svn: 315854
2017-10-15 22:32:27 +08:00
#if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP)
Rename AttributeSet to AttributeList Summary: This class is a list of AttributeSetNodes corresponding the function prototype of a call or function declaration. This class used to be called ParamAttrListPtr, then AttrListPtr, then AttributeSet. It is typically accessed by parameter and return value index, so "AttributeList" seems like a more intuitive name. Rename AttributeSetImpl to AttributeListImpl to follow suit. It's useful to rename this class so that we can rename AttributeSetNode to AttributeSet later. AttributeSet is the set of attributes that apply to a single function, argument, or return value. Reviewers: sanjoy, javed.absar, chandlerc, pete Reviewed By: pete Subscribers: pete, jholewinski, arsenm, dschuff, mehdi_amini, jfb, nhaehnle, sbc100, void, llvm-commits Differential Revision: https://reviews.llvm.org/D31102 llvm-svn: 298393
2017-03-22 00:57:19 +08:00
LLVM_DUMP_METHOD void AttributeList::dump() const {
Remove a use of AttributeWithIndex. We want to remove AttributeWithIndex because it provides a non-encapsulated view of the AttributeSetImpl object. Instead, use accessor methods and iterators. Eventually, this code can be simplified because the Attribute object will hold only one attribute instead of multiple attributes. llvm-svn: 173641
2013-01-28 08:21:34 +08:00
dbgs() << "PAL[\n";
Reorder some functions and add comments. No functionality change. llvm-svn: 173733
2013-01-29 08:34:06 +08:00
[IR] Switch AttributeList to use an array for O(1) access Summary: Before this change, AttributeLists stored a pair of index and AttributeSet. This is memory efficient if most arguments do not have attributes. However, it requires doing a search over the pairs to test an argument or function attribute. Profiling shows that this loop was 0.76% of the time in 'opt -O2' of sqlite3.c, because LLVM constantly tests values for nullability. This was worth about 2.5% of mid-level optimization cycles on the sqlite3 amalgamation. Here are the full perf results: https://reviews.llvm.org/P7995 Here are just the before and after cycle counts: ``` $ perf stat -r 5 ./opt_before -O2 sqlite3.bc -o /dev/null 13,274,181,184 cycles # 3.047 GHz ( +- 0.28% ) $ perf stat -r 5 ./opt_after -O2 sqlite3.bc -o /dev/null 12,906,927,263 cycles # 3.043 GHz ( +- 0.51% ) ``` This patch *does not* change the indices used to query attributes, as requested by reviewers. Tracking whether an index is usable for array indexing is a huge pain that affects many of the internal APIs, so it would be good to come back later and do a cleanup to remove this internal adjustment. Reviewers: pete, chandlerc Subscribers: javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D32819 llvm-svn: 303654
2017-05-24 01:01:48 +08:00
for (unsigned i = index_begin(), e = index_end(); i != e; ++i) {
if (getAttributes(i).hasAttributes())
dbgs() << " { " << i << " => " << getAsString(i) << " }\n";
Reimplement the parameter attributes support, phase #1. hilights: 1. There is now a "PAListPtr" class, which is a smart pointer around the underlying uniqued parameter attribute list object, and manages its refcount. It is now impossible to mess up the refcount. 2. PAListPtr is now the main interface to the underlying object, and the underlying object is now completely opaque. 3. Implementation details like SmallVector and FoldingSet are now no longer part of the interface. 4. You can create a PAListPtr with an arbitrary sequence of ParamAttrsWithIndex's, no need to make a SmallVector of a specific size (you can just use an array or scalar or vector if you wish). 5. All the client code that had to check for a null pointer before dereferencing the pointer is simplified to just access the PAListPtr directly. 6. The interfaces for adding attrs to a list and removing them is a bit simpler. Phase #2 will rename some stuff (e.g. PAListPtr) and do other less invasive changes. llvm-svn: 48289
2008-03-13 01:45:29 +08:00
}
Cleanup whitespace. llvm-svn: 166013
2012-10-16 14:01:44 +08:00
Change errs() to dbgs(). llvm-svn: 92658
2010-01-05 09:29:58 +08:00
dbgs() << "]\n";
The transform that tries to turn calls to bitcast functions into direct calls bails out unless caller and callee have essentially equivalent parameter attributes. This is illogical - the callee's attributes should be of no relevance here. Rework the logic, which incidentally fixes a crash when removed arguments have attributes. llvm-svn: 45658
2008-01-07 02:27:01 +08:00
}
Cleanup dump() functions. We had various variants of defining dump() functions in LLVM. Normalize them (this should just consistently implement the things discussed in http://lists.llvm.org/pipermail/cfe-dev/2014-January/034323.html For reference: - Public headers should just declare the dump() method but not use LLVM_DUMP_METHOD or #if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP) - The definition of a dump method should look like this: #if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP) LLVM_DUMP_METHOD void MyClass::dump() { // print stuff to dbgs()... } #endif llvm-svn: 293359
2017-01-28 10:02:38 +08:00
#endif
Remove some introspection functions. The 'getSlot' function and its ilk allow introspection into the AttributeSet class. However, that class should be opaque. Allow access through accessor methods instead. llvm-svn: 173522
2013-01-26 07:09:36 +08:00
Reorder some functions and add comments. No functionality change. llvm-svn: 173733
2013-01-29 08:34:06 +08:00
//===----------------------------------------------------------------------===//
// AttrBuilder Method Implementations
//===----------------------------------------------------------------------===//
[IR] Switch AttributeList to use an array for O(1) access Summary: Before this change, AttributeLists stored a pair of index and AttributeSet. This is memory efficient if most arguments do not have attributes. However, it requires doing a search over the pairs to test an argument or function attribute. Profiling shows that this loop was 0.76% of the time in 'opt -O2' of sqlite3.c, because LLVM constantly tests values for nullability. This was worth about 2.5% of mid-level optimization cycles on the sqlite3 amalgamation. Here are the full perf results: https://reviews.llvm.org/P7995 Here are just the before and after cycle counts: ``` $ perf stat -r 5 ./opt_before -O2 sqlite3.bc -o /dev/null 13,274,181,184 cycles # 3.047 GHz ( +- 0.28% ) $ perf stat -r 5 ./opt_after -O2 sqlite3.bc -o /dev/null 12,906,927,263 cycles # 3.043 GHz ( +- 0.51% ) ``` This patch *does not* change the indices used to query attributes, as requested by reviewers. Tracking whether an index is usable for array indexing is a huge pain that affects many of the internal APIs, so it would be good to come back later and do a cleanup to remove this internal adjustment. Reviewers: pete, chandlerc Subscribers: javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D32819 llvm-svn: 303654
2017-05-24 01:01:48 +08:00
// FIXME: Remove this ctor, use AttributeSet.
[IR] Add AttributeSet to hide AttributeSetNode* again, NFC Summary: For now, it just wraps AttributeSetNode*. Eventually, it will hold AvailableAttrs as an inline bitset, and adding and removing enum attributes will be super cheap. This sinks AttributeSetNode back down to lib/IR/AttributeImpl.h. Reviewers: pete, chandlerc Subscribers: llvm-commits, jfb Differential Revision: https://reviews.llvm.org/D31940 llvm-svn: 300014
2017-04-12 08:38:00 +08:00
AttrBuilder::AttrBuilder(AttributeList AL, unsigned Index) {
[IR] Switch AttributeList to use an array for O(1) access Summary: Before this change, AttributeLists stored a pair of index and AttributeSet. This is memory efficient if most arguments do not have attributes. However, it requires doing a search over the pairs to test an argument or function attribute. Profiling shows that this loop was 0.76% of the time in 'opt -O2' of sqlite3.c, because LLVM constantly tests values for nullability. This was worth about 2.5% of mid-level optimization cycles on the sqlite3 amalgamation. Here are the full perf results: https://reviews.llvm.org/P7995 Here are just the before and after cycle counts: ``` $ perf stat -r 5 ./opt_before -O2 sqlite3.bc -o /dev/null 13,274,181,184 cycles # 3.047 GHz ( +- 0.28% ) $ perf stat -r 5 ./opt_after -O2 sqlite3.bc -o /dev/null 12,906,927,263 cycles # 3.043 GHz ( +- 0.51% ) ``` This patch *does not* change the indices used to query attributes, as requested by reviewers. Tracking whether an index is usable for array indexing is a huge pain that affects many of the internal APIs, so it would be good to come back later and do a cleanup to remove this internal adjustment. Reviewers: pete, chandlerc Subscribers: javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D32819 llvm-svn: 303654
2017-05-24 01:01:48 +08:00
AttributeSet AS = AL.getAttributes(Index);
[IR] Fix some Clang-tidy modernize-use-auto warnings; other minor fixes (NFC). llvm-svn: 328850
2018-03-30 08:47:31 +08:00
for (const auto &A : AS)
[IR] Switch AttributeList to use an array for O(1) access Summary: Before this change, AttributeLists stored a pair of index and AttributeSet. This is memory efficient if most arguments do not have attributes. However, it requires doing a search over the pairs to test an argument or function attribute. Profiling shows that this loop was 0.76% of the time in 'opt -O2' of sqlite3.c, because LLVM constantly tests values for nullability. This was worth about 2.5% of mid-level optimization cycles on the sqlite3 amalgamation. Here are the full perf results: https://reviews.llvm.org/P7995 Here are just the before and after cycle counts: ``` $ perf stat -r 5 ./opt_before -O2 sqlite3.bc -o /dev/null 13,274,181,184 cycles # 3.047 GHz ( +- 0.28% ) $ perf stat -r 5 ./opt_after -O2 sqlite3.bc -o /dev/null 12,906,927,263 cycles # 3.043 GHz ( +- 0.51% ) ``` This patch *does not* change the indices used to query attributes, as requested by reviewers. Tracking whether an index is usable for array indexing is a huge pain that affects many of the internal APIs, so it would be good to come back later and do a cleanup to remove this internal adjustment. Reviewers: pete, chandlerc Subscribers: javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D32819 llvm-svn: 303654
2017-05-24 01:01:48 +08:00
addAttribute(A);
Reorder some functions and add comments. No functionality change. llvm-svn: 173733
2013-01-29 08:34:06 +08:00
}
[IR] Add AttributeSet to hide AttributeSetNode* again, NFC Summary: For now, it just wraps AttributeSetNode*. Eventually, it will hold AvailableAttrs as an inline bitset, and adding and removing enum attributes will be super cheap. This sinks AttributeSetNode back down to lib/IR/AttributeImpl.h. Reviewers: pete, chandlerc Subscribers: llvm-commits, jfb Differential Revision: https://reviews.llvm.org/D31940 llvm-svn: 300014
2017-04-12 08:38:00 +08:00
AttrBuilder::AttrBuilder(AttributeSet AS) {
[IR] Fix some Clang-tidy modernize-use-auto warnings; other minor fixes (NFC). llvm-svn: 328850
2018-03-30 08:47:31 +08:00
for (const auto &A : AS)
[IR] Switch AttributeList to use an array for O(1) access Summary: Before this change, AttributeLists stored a pair of index and AttributeSet. This is memory efficient if most arguments do not have attributes. However, it requires doing a search over the pairs to test an argument or function attribute. Profiling shows that this loop was 0.76% of the time in 'opt -O2' of sqlite3.c, because LLVM constantly tests values for nullability. This was worth about 2.5% of mid-level optimization cycles on the sqlite3 amalgamation. Here are the full perf results: https://reviews.llvm.org/P7995 Here are just the before and after cycle counts: ``` $ perf stat -r 5 ./opt_before -O2 sqlite3.bc -o /dev/null 13,274,181,184 cycles # 3.047 GHz ( +- 0.28% ) $ perf stat -r 5 ./opt_after -O2 sqlite3.bc -o /dev/null 12,906,927,263 cycles # 3.043 GHz ( +- 0.51% ) ``` This patch *does not* change the indices used to query attributes, as requested by reviewers. Tracking whether an index is usable for array indexing is a huge pain that affects many of the internal APIs, so it would be good to come back later and do a cleanup to remove this internal adjustment. Reviewers: pete, chandlerc Subscribers: javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D32819 llvm-svn: 303654
2017-05-24 01:01:48 +08:00
addAttribute(A);
Reland "[IR] Make AttributeSetNode public, avoid temporary AttributeList copies" This re-lands r299875. I introduced a bug in Clang code responsible for replacing K&R, no prototype declarations with a real function definition with a prototype. The bug was here: // Collect any return attributes from the call. - if (oldAttrs.hasAttributes(llvm::AttributeList::ReturnIndex)) - newAttrs.push_back(llvm::AttributeList::get(newFn->getContext(), - oldAttrs.getRetAttributes())); + newAttrs.push_back(oldAttrs.getRetAttributes()); Previously getRetAttributes() carried AttributeList::ReturnIndex in its AttributeList. Now that we return the AttributeSetNode* directly, it no longer carries that index, and we call this overload with a single node: AttributeList::get(LLVMContext&, ArrayRef<AttributeSetNode*>) That aborted with an assertion on x86_32 targets. I added an explicit triple to the test and added CHECKs to help find issues like this in the future sooner. llvm-svn: 299899
2017-04-11 07:31:05 +08:00
}
Reorder some functions and add comments. No functionality change. llvm-svn: 173733
2013-01-29 08:34:06 +08:00
void AttrBuilder::clear() {
Futureproof AttrBuild if we ever have more than 64 attr enum values. Currently we're at 34. Bitset should compile into virtually the same code as uint64_t here. llvm-svn: 175437
2013-02-18 20:09:51 +08:00
Attrs.reset();
[IR] Have AttrBuilder::clear clear `TargetDepAttrs`. Test case attached -- currently the parser smears the "foo bar" to all of the formal arguments. llvm-svn: 246812
2015-09-04 06:27:42 +08:00
TargetDepAttrs.clear();
[LLVM][Alignment] Introduce Alignment In Attributes Summary: This is patch is part of a serie to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: jfb Subscribers: hiraditya, dexonsmith, llvm-commits, courbet Tags: #llvm Differential Revision: https://reviews.llvm.org/D65742 llvm-svn: 368002
2019-08-06 17:16:33 +08:00
Alignment.reset();
StackAlignment.reset();
DerefBytes = DerefOrNullBytes = 0;
Add the allocsize attribute to LLVM. `allocsize` is a function attribute that allows users to request that LLVM treat arbitrary functions as allocation functions. This patch makes LLVM accept the `allocsize` attribute, and makes `@llvm.objectsize` recognize said attribute. The review for this was split into two patches for ease of reviewing: D18974 and D14933. As promised on the revisions, I'm landing both patches as a single commit. Differential Revision: http://reviews.llvm.org/D14933 llvm-svn: 266032
2016-04-12 09:05:35 +08:00
AllocSizeArgs = 0;
Reapply: IR: add optional type to 'byval' function parameters When we switch to opaque pointer types we will need some way to describe how many bytes a 'byval' parameter should occupy on the stack. This adds a (for now) optional extra type parameter. If present, the type must match the pointee type of the argument. The original commit did not remap byval types when linking modules, which broke LTO. This version fixes that. Note to front-end maintainers: if this causes test failures, it's probably because the "byval" attribute is printed after attributes without any parameter after this change. llvm-svn: 362128
2019-05-31 02:48:23 +08:00
ByValType = nullptr;
Reapply "OpaquePtr: Add type to sret attribute" This reverts commit eb9f7c28e5fe6d75fed3587023e17f2997c8024b. Previously this was incorrectly handling linking of the contained type, so this merges the fixes from D88973.
2020-09-29 21:33:55 +08:00
StructRetType = nullptr;
IR: Define byref parameter attribute This allows tracking the in-memory type of a pointer argument to a function for ABI purposes. This is essentially a stripped down version of byval to remove some of the stack-copy implications in its definition. This includes the base IR changes, and some tests for places where it should be treated similarly to byval. Codegen support will be in a future patch. My original attempt at solving some of these problems was to repurpose byval with a different address space from the stack. However, it is technically permitted for the callee to introduce a write to the argument, although nothing does this in reality. There is also talk of removing and replacing the byval attribute, so a new attribute would need to take its place anyway. This is intended avoid some optimization issues with the current handling of aggregate arguments, as well as fixes inflexibilty in how frontends can specify the kernel ABI. The most honest representation of the amdgpu_kernel convention is to expose all kernel arguments as loads from constant memory. Today, these are raw, SSA Argument values and codegen is responsible for turning these into loads. Background: There currently isn't a satisfactory way to represent how arguments for the amdgpu_kernel calling convention are passed. In reality, arguments are passed in a single, flat, constant memory buffer implicitly passed to the function. It is also illegal to call this function in the IR, and this is only ever invoked by a driver of some kind. It does not make sense to have a stack passed parameter in this context as is implied by byval. It is never valid to write to the kernel arguments, as this would corrupt the inputs seen by other dispatches of the kernel. These argumets are also not in the same address space as the stack, so a copy is needed to an alloca. From a source C-like language, the kernel parameters are invisible. Semantically, a copy is always required from the constant argument memory to a mutable variable. The current clang calling convention lowering emits raw values, including aggregates into the function argument list, since using byval would not make sense. This has some unfortunate consequences for the optimizer. In the aggregate case, we end up with an aggregate store to alloca, which both SROA and instcombine turn into a store of each aggregate field. The optimizer never pieces this back together to see that this is really just a copy from constant memory, so we end up stuck with expensive stack usage. This also means the backend dictates the alignment of arguments, and arbitrarily picks the LLVM IR ABI type alignment. By allowing an explicit alignment, frontends can make better decisions. For example, there's real no advantage to an aligment higher than 4, so a frontend could choose to compact the argument layout. Similarly, there is a high penalty to using an alignment lower than 4, so a frontend could opt into more padding for small arguments. Another design consideration is when it is appropriate to expose the fact that these arguments are all really passed in adjacent memory. Currently we have a late IR optimization pass in codegen to rewrite the kernel argument values into explicit loads to enable vectorization. In most programs, unrelated argument loads can be merged together. However, exposing this property directly from the frontend has some disadvantages. We still need a way to track the original argument sizes and alignments to report to the driver. I find using some side-channel, metadata mechanism to track this unappealing. If the kernel arguments were exposed as a single buffer to begin with, alias analysis would be unaware that the padding bits betewen arguments are meaningless. Another family of problems is there are still some gaps in replacing all of the available parameter attributes with metadata equivalents once lowered to loads. The immediate plan is to start using this new attribute to handle all aggregate argumets for kernels. Long term, it makes sense to migrate all kernel arguments, including scalars, to be passed indirectly in the same manner. Additional context is in D79744.
2020-06-06 04:58:47 +08:00
ByRefType = nullptr;
Add IR constructs for preallocated (inalloca replacement) Add llvm.call.preallocated.{setup,arg} instrinsics. Add "preallocated" operand bundle which takes a token produced by llvm.call.preallocated.setup. Add "preallocated" parameter attribute, which is like byval but without the copy. Verifier changes for these IR constructs. See https://github.com/rnk/llvm-project/blob/call-setup-docs/llvm/docs/CallSetup.md Subscribers: hiraditya, jdoerfert, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D74651
2020-02-15 06:16:53 +08:00
PreallocatedType = nullptr;
Reorder some functions and add comments. No functionality change. llvm-svn: 173733
2013-01-29 08:34:06 +08:00
}
s/AttrBuilder::addAttributes/AttrBuilder::addAttribute/g because that's more descriptive of what it actually is. llvm-svn: 174116
2013-02-01 07:38:01 +08:00
AttrBuilder &AttrBuilder::addAttribute(Attribute Attr) {
Handle string attributes in the AttrBuilder. llvm-svn: 174834
2013-02-10 18:13:23 +08:00
if (Attr.isStringAttribute()) {
addAttribute(Attr.getKindAsString(), Attr.getValueAsString());
return *this;
}
Convert to storing the attribute's internals as enums, integers, and strings. The stuff we're handing are all enums (Attribute::AttrKind), integers and strings. Don't convert them to Constants, which is an unnecessary step here. The rest of the changes are mostly mechanical. llvm-svn: 174456
2013-02-06 06:37:24 +08:00
Attribute::AttrKind Kind = Attr.getKindAsEnum();
Futureproof AttrBuild if we ever have more than 64 attr enum values. Currently we're at 34. Bitset should compile into virtually the same code as uint64_t here. llvm-svn: 175437
2013-02-18 20:09:51 +08:00
Attrs[Kind] = true;
Reorder some functions and add comments. No functionality change. llvm-svn: 173733
2013-01-29 08:34:06 +08:00
Convert to storing the attribute's internals as enums, integers, and strings. The stuff we're handing are all enums (Attribute::AttrKind), integers and strings. Don't convert them to Constants, which is an unnecessary step here. The rest of the changes are mostly mechanical. llvm-svn: 174456
2013-02-06 06:37:24 +08:00
if (Kind == Attribute::Alignment)
[Alignment][NFC] Use MaybeAlign in AttrBuilder Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69300 llvm-svn: 375496
2019-10-22 19:57:52 +08:00
Alignment = Attr.getAlignment();
Convert to storing the attribute's internals as enums, integers, and strings. The stuff we're handing are all enums (Attribute::AttrKind), integers and strings. Don't convert them to Constants, which is an unnecessary step here. The rest of the changes are mostly mechanical. llvm-svn: 174456
2013-02-06 06:37:24 +08:00
else if (Kind == Attribute::StackAlignment)
[Alignment][NFC] Use MaybeAlign in AttrBuilder Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69300 llvm-svn: 375496
2019-10-22 19:57:52 +08:00
StackAlignment = Attr.getStackAlignment();
Reapply: IR: add optional type to 'byval' function parameters When we switch to opaque pointer types we will need some way to describe how many bytes a 'byval' parameter should occupy on the stack. This adds a (for now) optional extra type parameter. If present, the type must match the pointee type of the argument. The original commit did not remap byval types when linking modules, which broke LTO. This version fixes that. Note to front-end maintainers: if this causes test failures, it's probably because the "byval" attribute is printed after attributes without any parameter after this change. llvm-svn: 362128
2019-05-31 02:48:23 +08:00
else if (Kind == Attribute::ByVal)
ByValType = Attr.getValueAsType();
Reapply "OpaquePtr: Add type to sret attribute" This reverts commit eb9f7c28e5fe6d75fed3587023e17f2997c8024b. Previously this was incorrectly handling linking of the contained type, so this merges the fixes from D88973.
2020-09-29 21:33:55 +08:00
else if (Kind == Attribute::StructRet)
StructRetType = Attr.getValueAsType();
IR: Define byref parameter attribute This allows tracking the in-memory type of a pointer argument to a function for ABI purposes. This is essentially a stripped down version of byval to remove some of the stack-copy implications in its definition. This includes the base IR changes, and some tests for places where it should be treated similarly to byval. Codegen support will be in a future patch. My original attempt at solving some of these problems was to repurpose byval with a different address space from the stack. However, it is technically permitted for the callee to introduce a write to the argument, although nothing does this in reality. There is also talk of removing and replacing the byval attribute, so a new attribute would need to take its place anyway. This is intended avoid some optimization issues with the current handling of aggregate arguments, as well as fixes inflexibilty in how frontends can specify the kernel ABI. The most honest representation of the amdgpu_kernel convention is to expose all kernel arguments as loads from constant memory. Today, these are raw, SSA Argument values and codegen is responsible for turning these into loads. Background: There currently isn't a satisfactory way to represent how arguments for the amdgpu_kernel calling convention are passed. In reality, arguments are passed in a single, flat, constant memory buffer implicitly passed to the function. It is also illegal to call this function in the IR, and this is only ever invoked by a driver of some kind. It does not make sense to have a stack passed parameter in this context as is implied by byval. It is never valid to write to the kernel arguments, as this would corrupt the inputs seen by other dispatches of the kernel. These argumets are also not in the same address space as the stack, so a copy is needed to an alloca. From a source C-like language, the kernel parameters are invisible. Semantically, a copy is always required from the constant argument memory to a mutable variable. The current clang calling convention lowering emits raw values, including aggregates into the function argument list, since using byval would not make sense. This has some unfortunate consequences for the optimizer. In the aggregate case, we end up with an aggregate store to alloca, which both SROA and instcombine turn into a store of each aggregate field. The optimizer never pieces this back together to see that this is really just a copy from constant memory, so we end up stuck with expensive stack usage. This also means the backend dictates the alignment of arguments, and arbitrarily picks the LLVM IR ABI type alignment. By allowing an explicit alignment, frontends can make better decisions. For example, there's real no advantage to an aligment higher than 4, so a frontend could choose to compact the argument layout. Similarly, there is a high penalty to using an alignment lower than 4, so a frontend could opt into more padding for small arguments. Another design consideration is when it is appropriate to expose the fact that these arguments are all really passed in adjacent memory. Currently we have a late IR optimization pass in codegen to rewrite the kernel argument values into explicit loads to enable vectorization. In most programs, unrelated argument loads can be merged together. However, exposing this property directly from the frontend has some disadvantages. We still need a way to track the original argument sizes and alignments to report to the driver. I find using some side-channel, metadata mechanism to track this unappealing. If the kernel arguments were exposed as a single buffer to begin with, alias analysis would be unaware that the padding bits betewen arguments are meaningless. Another family of problems is there are still some gaps in replacing all of the available parameter attributes with metadata equivalents once lowered to loads. The immediate plan is to start using this new attribute to handle all aggregate argumets for kernels. Long term, it makes sense to migrate all kernel arguments, including scalars, to be passed indirectly in the same manner. Additional context is in D79744.
2020-06-06 04:58:47 +08:00
else if (Kind == Attribute::ByRef)
ByRefType = Attr.getValueAsType();
Add IR constructs for preallocated (inalloca replacement) Add llvm.call.preallocated.{setup,arg} instrinsics. Add "preallocated" operand bundle which takes a token produced by llvm.call.preallocated.setup. Add "preallocated" parameter attribute, which is like byval but without the copy. Verifier changes for these IR constructs. See https://github.com/rnk/llvm-project/blob/call-setup-docs/llvm/docs/CallSetup.md Subscribers: hiraditya, jdoerfert, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D74651
2020-02-15 06:16:53 +08:00
else if (Kind == Attribute::Preallocated)
PreallocatedType = Attr.getValueAsType();
Add a dereferenceable attribute This attribute indicates that the parameter or return pointer is dereferenceable. Practically speaking, loads from such a pointer within the associated byte range are safe to speculatively execute. Such pointer parameters are common in source languages (C++ references, for example). llvm-svn: 213385
2014-07-18 23:51:28 +08:00
else if (Kind == Attribute::Dereferenceable)
DerefBytes = Attr.getDereferenceableBytes();
[IR] Introduce a dereferenceable_or_null(N) attribute. Summary: If a pointer is marked as dereferenceable_or_null(N), LLVM assumes it is either `null` or `dereferenceable(N)` or both. This change only introduces the attribute and adds a token test case for the `llvm-as` / `llvm-dis`. It does not hook up other parts of the optimizer to actually exploit the attribute -- those changes will come later. For pointers in address space 0, `dereferenceable(N)` is now exactly equivalent to `dereferenceable_or_null(N)` && `nonnull`. For other address spaces, `dereferenceable(N)` is potentially weaker than `dereferenceable_or_null(N)` && `nonnull` (since we could have a null `dereferenceable(N)` pointer). The motivating case for this change is Java (and other managed languages), where pointers are either `null` or dereferenceable up to some usually known-at-compile-time constant offset. Reviewers: rafael, hfinkel Reviewed By: hfinkel Subscribers: nicholas, llvm-commits Differential Revision: http://reviews.llvm.org/D8650 llvm-svn: 235132
2015-04-17 04:29:50 +08:00
else if (Kind == Attribute::DereferenceableOrNull)
DerefOrNullBytes = Attr.getDereferenceableOrNullBytes();
Add the allocsize attribute to LLVM. `allocsize` is a function attribute that allows users to request that LLVM treat arbitrary functions as allocation functions. This patch makes LLVM accept the `allocsize` attribute, and makes `@llvm.objectsize` recognize said attribute. The review for this was split into two patches for ease of reviewing: D18974 and D14933. As promised on the revisions, I'm landing both patches as a single commit. Differential Revision: http://reviews.llvm.org/D14933 llvm-svn: 266032
2016-04-12 09:05:35 +08:00
else if (Kind == Attribute::AllocSize)
AllocSizeArgs = Attr.getValueAsInt();
Reorder some functions and add comments. No functionality change. llvm-svn: 173733
2013-01-29 08:34:06 +08:00
return *this;
}
Add target-dependent versions of addAttribute/removeAttribute to AttrBuilder. llvm-svn: 174356
2013-02-05 16:09:32 +08:00
AttrBuilder &AttrBuilder::addAttribute(StringRef A, StringRef V) {
Make llvm::StringRef to std::string conversions explicit. This is how it should've been and brings it more in line with std::string_view. There should be no functional change here. This is mostly mechanical from a custom clang-tidy check, with a lot of manual fixups. It uncovers a lot of minor inefficiencies. This doesn't actually modify StringRef yet, I'll do that in a follow-up.
2020-01-29 03:23:46 +08:00
TargetDepAttrs[std::string(A)] = std::string(V);
Add target-dependent versions of addAttribute/removeAttribute to AttrBuilder. llvm-svn: 174356
2013-02-05 16:09:32 +08:00
return *this;
}
s/AttrBuilder::addAttributes/AttrBuilder::addAttribute/g because that's more descriptive of what it actually is. llvm-svn: 174116
2013-02-01 07:38:01 +08:00
AttrBuilder &AttrBuilder::removeAttribute(Attribute::AttrKind Val) {
Futureproof AttrBuild if we ever have more than 64 attr enum values. Currently we're at 34. Bitset should compile into virtually the same code as uint64_t here. llvm-svn: 175437
2013-02-18 20:09:51 +08:00
assert((unsigned)Val < Attribute::EndAttrKinds && "Attribute out of range!");
Attrs[Val] = false;
s/AttrBuilder::addAttributes/AttrBuilder::addAttribute/g because that's more descriptive of what it actually is. llvm-svn: 174116
2013-02-01 07:38:01 +08:00
if (Val == Attribute::Alignment)
[LLVM][Alignment] Introduce Alignment In Attributes Summary: This is patch is part of a serie to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: jfb Subscribers: hiraditya, dexonsmith, llvm-commits, courbet Tags: #llvm Differential Revision: https://reviews.llvm.org/D65742 llvm-svn: 368002
2019-08-06 17:16:33 +08:00
Alignment.reset();
s/AttrBuilder::addAttributes/AttrBuilder::addAttribute/g because that's more descriptive of what it actually is. llvm-svn: 174116
2013-02-01 07:38:01 +08:00
else if (Val == Attribute::StackAlignment)
[LLVM][Alignment] Introduce Alignment In Attributes Summary: This is patch is part of a serie to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: jfb Subscribers: hiraditya, dexonsmith, llvm-commits, courbet Tags: #llvm Differential Revision: https://reviews.llvm.org/D65742 llvm-svn: 368002
2019-08-06 17:16:33 +08:00
StackAlignment.reset();
Reapply: IR: add optional type to 'byval' function parameters When we switch to opaque pointer types we will need some way to describe how many bytes a 'byval' parameter should occupy on the stack. This adds a (for now) optional extra type parameter. If present, the type must match the pointee type of the argument. The original commit did not remap byval types when linking modules, which broke LTO. This version fixes that. Note to front-end maintainers: if this causes test failures, it's probably because the "byval" attribute is printed after attributes without any parameter after this change. llvm-svn: 362128
2019-05-31 02:48:23 +08:00
else if (Val == Attribute::ByVal)
ByValType = nullptr;
Reapply "OpaquePtr: Add type to sret attribute" This reverts commit eb9f7c28e5fe6d75fed3587023e17f2997c8024b. Previously this was incorrectly handling linking of the contained type, so this merges the fixes from D88973.
2020-09-29 21:33:55 +08:00
else if (Val == Attribute::StructRet)
StructRetType = nullptr;
IR: Define byref parameter attribute This allows tracking the in-memory type of a pointer argument to a function for ABI purposes. This is essentially a stripped down version of byval to remove some of the stack-copy implications in its definition. This includes the base IR changes, and some tests for places where it should be treated similarly to byval. Codegen support will be in a future patch. My original attempt at solving some of these problems was to repurpose byval with a different address space from the stack. However, it is technically permitted for the callee to introduce a write to the argument, although nothing does this in reality. There is also talk of removing and replacing the byval attribute, so a new attribute would need to take its place anyway. This is intended avoid some optimization issues with the current handling of aggregate arguments, as well as fixes inflexibilty in how frontends can specify the kernel ABI. The most honest representation of the amdgpu_kernel convention is to expose all kernel arguments as loads from constant memory. Today, these are raw, SSA Argument values and codegen is responsible for turning these into loads. Background: There currently isn't a satisfactory way to represent how arguments for the amdgpu_kernel calling convention are passed. In reality, arguments are passed in a single, flat, constant memory buffer implicitly passed to the function. It is also illegal to call this function in the IR, and this is only ever invoked by a driver of some kind. It does not make sense to have a stack passed parameter in this context as is implied by byval. It is never valid to write to the kernel arguments, as this would corrupt the inputs seen by other dispatches of the kernel. These argumets are also not in the same address space as the stack, so a copy is needed to an alloca. From a source C-like language, the kernel parameters are invisible. Semantically, a copy is always required from the constant argument memory to a mutable variable. The current clang calling convention lowering emits raw values, including aggregates into the function argument list, since using byval would not make sense. This has some unfortunate consequences for the optimizer. In the aggregate case, we end up with an aggregate store to alloca, which both SROA and instcombine turn into a store of each aggregate field. The optimizer never pieces this back together to see that this is really just a copy from constant memory, so we end up stuck with expensive stack usage. This also means the backend dictates the alignment of arguments, and arbitrarily picks the LLVM IR ABI type alignment. By allowing an explicit alignment, frontends can make better decisions. For example, there's real no advantage to an aligment higher than 4, so a frontend could choose to compact the argument layout. Similarly, there is a high penalty to using an alignment lower than 4, so a frontend could opt into more padding for small arguments. Another design consideration is when it is appropriate to expose the fact that these arguments are all really passed in adjacent memory. Currently we have a late IR optimization pass in codegen to rewrite the kernel argument values into explicit loads to enable vectorization. In most programs, unrelated argument loads can be merged together. However, exposing this property directly from the frontend has some disadvantages. We still need a way to track the original argument sizes and alignments to report to the driver. I find using some side-channel, metadata mechanism to track this unappealing. If the kernel arguments were exposed as a single buffer to begin with, alias analysis would be unaware that the padding bits betewen arguments are meaningless. Another family of problems is there are still some gaps in replacing all of the available parameter attributes with metadata equivalents once lowered to loads. The immediate plan is to start using this new attribute to handle all aggregate argumets for kernels. Long term, it makes sense to migrate all kernel arguments, including scalars, to be passed indirectly in the same manner. Additional context is in D79744.
2020-06-06 04:58:47 +08:00
else if (Val == Attribute::ByRef)
ByRefType = nullptr;
Add IR constructs for preallocated (inalloca replacement) Add llvm.call.preallocated.{setup,arg} instrinsics. Add "preallocated" operand bundle which takes a token produced by llvm.call.preallocated.setup. Add "preallocated" parameter attribute, which is like byval but without the copy. Verifier changes for these IR constructs. See https://github.com/rnk/llvm-project/blob/call-setup-docs/llvm/docs/CallSetup.md Subscribers: hiraditya, jdoerfert, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D74651
2020-02-15 06:16:53 +08:00
else if (Val == Attribute::Preallocated)
PreallocatedType = nullptr;
Add a dereferenceable attribute This attribute indicates that the parameter or return pointer is dereferenceable. Practically speaking, loads from such a pointer within the associated byte range are safe to speculatively execute. Such pointer parameters are common in source languages (C++ references, for example). llvm-svn: 213385
2014-07-18 23:51:28 +08:00
else if (Val == Attribute::Dereferenceable)
DerefBytes = 0;
[IR] Introduce a dereferenceable_or_null(N) attribute. Summary: If a pointer is marked as dereferenceable_or_null(N), LLVM assumes it is either `null` or `dereferenceable(N)` or both. This change only introduces the attribute and adds a token test case for the `llvm-as` / `llvm-dis`. It does not hook up other parts of the optimizer to actually exploit the attribute -- those changes will come later. For pointers in address space 0, `dereferenceable(N)` is now exactly equivalent to `dereferenceable_or_null(N)` && `nonnull`. For other address spaces, `dereferenceable(N)` is potentially weaker than `dereferenceable_or_null(N)` && `nonnull` (since we could have a null `dereferenceable(N)` pointer). The motivating case for this change is Java (and other managed languages), where pointers are either `null` or dereferenceable up to some usually known-at-compile-time constant offset. Reviewers: rafael, hfinkel Reviewed By: hfinkel Subscribers: nicholas, llvm-commits Differential Revision: http://reviews.llvm.org/D8650 llvm-svn: 235132
2015-04-17 04:29:50 +08:00
else if (Val == Attribute::DereferenceableOrNull)
DerefOrNullBytes = 0;
Add the allocsize attribute to LLVM. `allocsize` is a function attribute that allows users to request that LLVM treat arbitrary functions as allocation functions. This patch makes LLVM accept the `allocsize` attribute, and makes `@llvm.objectsize` recognize said attribute. The review for this was split into two patches for ease of reviewing: D18974 and D14933. As promised on the revisions, I'm landing both patches as a single commit. Differential Revision: http://reviews.llvm.org/D14933 llvm-svn: 266032
2016-04-12 09:05:35 +08:00
else if (Val == Attribute::AllocSize)
AllocSizeArgs = 0;
s/AttrBuilder::addAttributes/AttrBuilder::addAttribute/g because that's more descriptive of what it actually is. llvm-svn: 174116
2013-02-01 07:38:01 +08:00
return *this;
}
Rename AttributeSet to AttributeList Summary: This class is a list of AttributeSetNodes corresponding the function prototype of a call or function declaration. This class used to be called ParamAttrListPtr, then AttrListPtr, then AttributeSet. It is typically accessed by parameter and return value index, so "AttributeList" seems like a more intuitive name. Rename AttributeSetImpl to AttributeListImpl to follow suit. It's useful to rename this class so that we can rename AttributeSetNode to AttributeSet later. AttributeSet is the set of attributes that apply to a single function, argument, or return value. Reviewers: sanjoy, javed.absar, chandlerc, pete Reviewed By: pete Subscribers: pete, jholewinski, arsenm, dschuff, mehdi_amini, jfb, nhaehnle, sbc100, void, llvm-commits Differential Revision: https://reviews.llvm.org/D31102 llvm-svn: 298393
2017-03-22 00:57:19 +08:00
AttrBuilder &AttrBuilder::removeAttributes(AttributeList A, uint64_t Index) {
Use Argument::hasAttribute and AttributeList::ReturnIndex more This eliminates many extra 'Idx' induction variables in loops over arguments in CodeGen/ and Target/. It also reduces the number of places where we assume that ReturnIndex is 0 and that we should add one to argument numbers to get the corresponding attribute list index. NFC llvm-svn: 301666
2017-04-29 02:37:16 +08:00
remove(A.getAttributes(Index));
Reorder some functions and add comments. No functionality change. llvm-svn: 173733
2013-01-29 08:34:06 +08:00
return *this;
}
Add target-dependent versions of addAttribute/removeAttribute to AttrBuilder. llvm-svn: 174356
2013-02-05 16:09:32 +08:00
AttrBuilder &AttrBuilder::removeAttribute(StringRef A) {
[IR] Fix some Clang-tidy modernize-use-auto warnings; other minor fixes (NFC). llvm-svn: 328850
2018-03-30 08:47:31 +08:00
auto I = TargetDepAttrs.find(A);
Add target-dependent versions of addAttribute/removeAttribute to AttrBuilder. llvm-svn: 174356
2013-02-05 16:09:32 +08:00
if (I != TargetDepAttrs.end())
TargetDepAttrs.erase(I);
return *this;
}
Add the allocsize attribute to LLVM. `allocsize` is a function attribute that allows users to request that LLVM treat arbitrary functions as allocation functions. This patch makes LLVM accept the `allocsize` attribute, and makes `@llvm.objectsize` recognize said attribute. The review for this was split into two patches for ease of reviewing: D18974 and D14933. As promised on the revisions, I'm landing both patches as a single commit. Differential Revision: http://reviews.llvm.org/D14933 llvm-svn: 266032
2016-04-12 09:05:35 +08:00
std::pair<unsigned, Optional<unsigned>> AttrBuilder::getAllocSizeArgs() const {
return unpackAllocSizeArgs(AllocSizeArgs);
}
[Alignment][NFC] Attributes use Align/MaybeAlign Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Subscribers: jholewinski, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69278 llvm-svn: 375495
2019-10-22 17:51:06 +08:00
AttrBuilder &AttrBuilder::addAlignmentAttr(MaybeAlign Align) {
[LLVM][Alignment] Introduce Alignment In Attributes Summary: This is patch is part of a serie to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: jfb Subscribers: hiraditya, dexonsmith, llvm-commits, courbet Tags: #llvm Differential Revision: https://reviews.llvm.org/D65742 llvm-svn: 368002
2019-08-06 17:16:33 +08:00
if (!Align)
return *this;
Reorder some functions and add comments. No functionality change. llvm-svn: 173733
2013-01-29 08:34:06 +08:00
[IR] Attribute/AttrBuilder: use Value::MaximumAlignment magic constant Summary: I initially encountered those assertions when trying to create this IR `alignment` attribute from clang's `__attribute__((assume_aligned(imm)))`, because until D72994 there is no sanity checking for the value of `imm`. But even then, we have `llvm::Value::MaximumAlignment` constant (which is `536870912`), which is enforced for clang attributes, and then there are some other magical constant (`0x40000000` i.e. `1073741824` i.e. `2 * 536870912`) in `Attribute::getWithAlignment()`/`AttrBuilder::addAlignmentAttr()`. I strongly suspect that `0x40000000` is incorrect, and that also should be `llvm::Value::MaximumAlignment`. Reviewers: erichkeane, hfinkel, jdoerfert, gchatelet, courbet Reviewed By: erichkeane Subscribers: hiraditya, cfe-commits, llvm-commits Tags: #llvm, #clang Differential Revision: https://reviews.llvm.org/D72998
2020-01-24 03:50:06 +08:00
assert(*Align <= llvm::Value::MaximumAlignment && "Alignment too large.");
Reorder some functions and add comments. No functionality change. llvm-svn: 173733
2013-01-29 08:34:06 +08:00
Futureproof AttrBuild if we ever have more than 64 attr enum values. Currently we're at 34. Bitset should compile into virtually the same code as uint64_t here. llvm-svn: 175437
2013-02-18 20:09:51 +08:00
Attrs[Attribute::Alignment] = true;
Reorder some functions and add comments. No functionality change. llvm-svn: 173733
2013-01-29 08:34:06 +08:00
Alignment = Align;
return *this;
}
[Alignment][NFC] Attributes use Align/MaybeAlign Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Subscribers: jholewinski, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69278 llvm-svn: 375495
2019-10-22 17:51:06 +08:00
AttrBuilder &AttrBuilder::addStackAlignmentAttr(MaybeAlign Align) {
Reorder some functions and add comments. No functionality change. llvm-svn: 173733
2013-01-29 08:34:06 +08:00
// Default alignment, allow the target to define how to align it.
[LLVM][Alignment] Introduce Alignment In Attributes Summary: This is patch is part of a serie to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: jfb Subscribers: hiraditya, dexonsmith, llvm-commits, courbet Tags: #llvm Differential Revision: https://reviews.llvm.org/D65742 llvm-svn: 368002
2019-08-06 17:16:33 +08:00
if (!Align)
return *this;
Reorder some functions and add comments. No functionality change. llvm-svn: 173733
2013-01-29 08:34:06 +08:00
[LLVM][Alignment] Introduce Alignment In Attributes Summary: This is patch is part of a serie to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: jfb Subscribers: hiraditya, dexonsmith, llvm-commits, courbet Tags: #llvm Differential Revision: https://reviews.llvm.org/D65742 llvm-svn: 368002
2019-08-06 17:16:33 +08:00
assert(*Align <= 0x100 && "Alignment too large.");
Reorder some functions and add comments. No functionality change. llvm-svn: 173733
2013-01-29 08:34:06 +08:00
Futureproof AttrBuild if we ever have more than 64 attr enum values. Currently we're at 34. Bitset should compile into virtually the same code as uint64_t here. llvm-svn: 175437
2013-02-18 20:09:51 +08:00
Attrs[Attribute::StackAlignment] = true;
Reorder some functions and add comments. No functionality change. llvm-svn: 173733
2013-01-29 08:34:06 +08:00
StackAlignment = Align;
return *this;
}
Add a dereferenceable attribute This attribute indicates that the parameter or return pointer is dereferenceable. Practically speaking, loads from such a pointer within the associated byte range are safe to speculatively execute. Such pointer parameters are common in source languages (C++ references, for example). llvm-svn: 213385
2014-07-18 23:51:28 +08:00
AttrBuilder &AttrBuilder::addDereferenceableAttr(uint64_t Bytes) {
if (Bytes == 0) return *this;
Attrs[Attribute::Dereferenceable] = true;
DerefBytes = Bytes;
return *this;
}
[IR] Introduce a dereferenceable_or_null(N) attribute. Summary: If a pointer is marked as dereferenceable_or_null(N), LLVM assumes it is either `null` or `dereferenceable(N)` or both. This change only introduces the attribute and adds a token test case for the `llvm-as` / `llvm-dis`. It does not hook up other parts of the optimizer to actually exploit the attribute -- those changes will come later. For pointers in address space 0, `dereferenceable(N)` is now exactly equivalent to `dereferenceable_or_null(N)` && `nonnull`. For other address spaces, `dereferenceable(N)` is potentially weaker than `dereferenceable_or_null(N)` && `nonnull` (since we could have a null `dereferenceable(N)` pointer). The motivating case for this change is Java (and other managed languages), where pointers are either `null` or dereferenceable up to some usually known-at-compile-time constant offset. Reviewers: rafael, hfinkel Reviewed By: hfinkel Subscribers: nicholas, llvm-commits Differential Revision: http://reviews.llvm.org/D8650 llvm-svn: 235132
2015-04-17 04:29:50 +08:00
AttrBuilder &AttrBuilder::addDereferenceableOrNullAttr(uint64_t Bytes) {
if (Bytes == 0)
return *this;
Attrs[Attribute::DereferenceableOrNull] = true;
DerefOrNullBytes = Bytes;
return *this;
}
Add the allocsize attribute to LLVM. `allocsize` is a function attribute that allows users to request that LLVM treat arbitrary functions as allocation functions. This patch makes LLVM accept the `allocsize` attribute, and makes `@llvm.objectsize` recognize said attribute. The review for this was split into two patches for ease of reviewing: D18974 and D14933. As promised on the revisions, I'm landing both patches as a single commit. Differential Revision: http://reviews.llvm.org/D14933 llvm-svn: 266032
2016-04-12 09:05:35 +08:00
AttrBuilder &AttrBuilder::addAllocSizeAttr(unsigned ElemSize,
const Optional<unsigned> &NumElems) {
return addAllocSizeAttrFromRawRepr(packAllocSizeArgs(ElemSize, NumElems));
}
AttrBuilder &AttrBuilder::addAllocSizeAttrFromRawRepr(uint64_t RawArgs) {
// (0, 0) is our "not present" value, so we need to check for it here.
assert(RawArgs && "Invalid allocsize arguments -- given allocsize(0, 0)");
Attrs[Attribute::AllocSize] = true;
// Reuse existing machinery to store this as a single 64-bit integer so we can
// save a few bytes over using a pair<unsigned, Optional<unsigned>>.
AllocSizeArgs = RawArgs;
return *this;
}
Reapply: IR: add optional type to 'byval' function parameters When we switch to opaque pointer types we will need some way to describe how many bytes a 'byval' parameter should occupy on the stack. This adds a (for now) optional extra type parameter. If present, the type must match the pointee type of the argument. The original commit did not remap byval types when linking modules, which broke LTO. This version fixes that. Note to front-end maintainers: if this causes test failures, it's probably because the "byval" attribute is printed after attributes without any parameter after this change. llvm-svn: 362128
2019-05-31 02:48:23 +08:00
AttrBuilder &AttrBuilder::addByValAttr(Type *Ty) {
Attrs[Attribute::ByVal] = true;
ByValType = Ty;
return *this;
}
Reapply "OpaquePtr: Add type to sret attribute" This reverts commit eb9f7c28e5fe6d75fed3587023e17f2997c8024b. Previously this was incorrectly handling linking of the contained type, so this merges the fixes from D88973.
2020-09-29 21:33:55 +08:00
AttrBuilder &AttrBuilder::addStructRetAttr(Type *Ty) {
Attrs[Attribute::StructRet] = true;
StructRetType = Ty;
return *this;
}
IR: Define byref parameter attribute This allows tracking the in-memory type of a pointer argument to a function for ABI purposes. This is essentially a stripped down version of byval to remove some of the stack-copy implications in its definition. This includes the base IR changes, and some tests for places where it should be treated similarly to byval. Codegen support will be in a future patch. My original attempt at solving some of these problems was to repurpose byval with a different address space from the stack. However, it is technically permitted for the callee to introduce a write to the argument, although nothing does this in reality. There is also talk of removing and replacing the byval attribute, so a new attribute would need to take its place anyway. This is intended avoid some optimization issues with the current handling of aggregate arguments, as well as fixes inflexibilty in how frontends can specify the kernel ABI. The most honest representation of the amdgpu_kernel convention is to expose all kernel arguments as loads from constant memory. Today, these are raw, SSA Argument values and codegen is responsible for turning these into loads. Background: There currently isn't a satisfactory way to represent how arguments for the amdgpu_kernel calling convention are passed. In reality, arguments are passed in a single, flat, constant memory buffer implicitly passed to the function. It is also illegal to call this function in the IR, and this is only ever invoked by a driver of some kind. It does not make sense to have a stack passed parameter in this context as is implied by byval. It is never valid to write to the kernel arguments, as this would corrupt the inputs seen by other dispatches of the kernel. These argumets are also not in the same address space as the stack, so a copy is needed to an alloca. From a source C-like language, the kernel parameters are invisible. Semantically, a copy is always required from the constant argument memory to a mutable variable. The current clang calling convention lowering emits raw values, including aggregates into the function argument list, since using byval would not make sense. This has some unfortunate consequences for the optimizer. In the aggregate case, we end up with an aggregate store to alloca, which both SROA and instcombine turn into a store of each aggregate field. The optimizer never pieces this back together to see that this is really just a copy from constant memory, so we end up stuck with expensive stack usage. This also means the backend dictates the alignment of arguments, and arbitrarily picks the LLVM IR ABI type alignment. By allowing an explicit alignment, frontends can make better decisions. For example, there's real no advantage to an aligment higher than 4, so a frontend could choose to compact the argument layout. Similarly, there is a high penalty to using an alignment lower than 4, so a frontend could opt into more padding for small arguments. Another design consideration is when it is appropriate to expose the fact that these arguments are all really passed in adjacent memory. Currently we have a late IR optimization pass in codegen to rewrite the kernel argument values into explicit loads to enable vectorization. In most programs, unrelated argument loads can be merged together. However, exposing this property directly from the frontend has some disadvantages. We still need a way to track the original argument sizes and alignments to report to the driver. I find using some side-channel, metadata mechanism to track this unappealing. If the kernel arguments were exposed as a single buffer to begin with, alias analysis would be unaware that the padding bits betewen arguments are meaningless. Another family of problems is there are still some gaps in replacing all of the available parameter attributes with metadata equivalents once lowered to loads. The immediate plan is to start using this new attribute to handle all aggregate argumets for kernels. Long term, it makes sense to migrate all kernel arguments, including scalars, to be passed indirectly in the same manner. Additional context is in D79744.
2020-06-06 04:58:47 +08:00
AttrBuilder &AttrBuilder::addByRefAttr(Type *Ty) {
Attrs[Attribute::ByRef] = true;
ByRefType = Ty;
return *this;
}
Add IR constructs for preallocated (inalloca replacement) Add llvm.call.preallocated.{setup,arg} instrinsics. Add "preallocated" operand bundle which takes a token produced by llvm.call.preallocated.setup. Add "preallocated" parameter attribute, which is like byval but without the copy. Verifier changes for these IR constructs. See https://github.com/rnk/llvm-project/blob/call-setup-docs/llvm/docs/CallSetup.md Subscribers: hiraditya, jdoerfert, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D74651
2020-02-15 06:16:53 +08:00
AttrBuilder &AttrBuilder::addPreallocatedAttr(Type *Ty) {
Attrs[Attribute::Preallocated] = true;
PreallocatedType = Ty;
return *this;
}
Add methods to merge an AttrBuilder into another builder. This is useful when parsing an object that references multiple attribute groups. N.B. If both builders have alignments specified, then they should match! llvm-svn: 174480
2013-02-06 09:16:00 +08:00
AttrBuilder &AttrBuilder::merge(const AttrBuilder &B) {
// FIXME: What if both have alignments, but they don't match?!
if (!Alignment)
Alignment = B.Alignment;
if (!StackAlignment)
StackAlignment = B.StackAlignment;
Add a dereferenceable attribute This attribute indicates that the parameter or return pointer is dereferenceable. Practically speaking, loads from such a pointer within the associated byte range are safe to speculatively execute. Such pointer parameters are common in source languages (C++ references, for example). llvm-svn: 213385
2014-07-18 23:51:28 +08:00
if (!DerefBytes)
DerefBytes = B.DerefBytes;
Add remove method to operate on AttrBuilder instead of AttributeSet. Prior to this change we would have to construct a temporary AttributeSet (which isn't temporary at all given that its allocated on the context), just to contain the attributes in the builder, then call remove on that. Now we can just remove any attributes from the (lightweight and really temporary) builder itself. Will be used in a future commit to remove some temporary attributes sets. llvm-svn: 236666
2015-05-07 07:19:43 +08:00
if (!DerefOrNullBytes)
DerefOrNullBytes = B.DerefOrNullBytes;
Add the allocsize attribute to LLVM. `allocsize` is a function attribute that allows users to request that LLVM treat arbitrary functions as allocation functions. This patch makes LLVM accept the `allocsize` attribute, and makes `@llvm.objectsize` recognize said attribute. The review for this was split into two patches for ease of reviewing: D18974 and D14933. As promised on the revisions, I'm landing both patches as a single commit. Differential Revision: http://reviews.llvm.org/D14933 llvm-svn: 266032
2016-04-12 09:05:35 +08:00
if (!AllocSizeArgs)
AllocSizeArgs = B.AllocSizeArgs;
Reapply: IR: add optional type to 'byval' function parameters When we switch to opaque pointer types we will need some way to describe how many bytes a 'byval' parameter should occupy on the stack. This adds a (for now) optional extra type parameter. If present, the type must match the pointee type of the argument. The original commit did not remap byval types when linking modules, which broke LTO. This version fixes that. Note to front-end maintainers: if this causes test failures, it's probably because the "byval" attribute is printed after attributes without any parameter after this change. llvm-svn: 362128
2019-05-31 02:48:23 +08:00
if (!ByValType)
ByValType = B.ByValType;
Reapply "OpaquePtr: Add type to sret attribute" This reverts commit eb9f7c28e5fe6d75fed3587023e17f2997c8024b. Previously this was incorrectly handling linking of the contained type, so this merges the fixes from D88973.
2020-09-29 21:33:55 +08:00
if (!StructRetType)
StructRetType = B.StructRetType;
IR: Define byref parameter attribute This allows tracking the in-memory type of a pointer argument to a function for ABI purposes. This is essentially a stripped down version of byval to remove some of the stack-copy implications in its definition. This includes the base IR changes, and some tests for places where it should be treated similarly to byval. Codegen support will be in a future patch. My original attempt at solving some of these problems was to repurpose byval with a different address space from the stack. However, it is technically permitted for the callee to introduce a write to the argument, although nothing does this in reality. There is also talk of removing and replacing the byval attribute, so a new attribute would need to take its place anyway. This is intended avoid some optimization issues with the current handling of aggregate arguments, as well as fixes inflexibilty in how frontends can specify the kernel ABI. The most honest representation of the amdgpu_kernel convention is to expose all kernel arguments as loads from constant memory. Today, these are raw, SSA Argument values and codegen is responsible for turning these into loads. Background: There currently isn't a satisfactory way to represent how arguments for the amdgpu_kernel calling convention are passed. In reality, arguments are passed in a single, flat, constant memory buffer implicitly passed to the function. It is also illegal to call this function in the IR, and this is only ever invoked by a driver of some kind. It does not make sense to have a stack passed parameter in this context as is implied by byval. It is never valid to write to the kernel arguments, as this would corrupt the inputs seen by other dispatches of the kernel. These argumets are also not in the same address space as the stack, so a copy is needed to an alloca. From a source C-like language, the kernel parameters are invisible. Semantically, a copy is always required from the constant argument memory to a mutable variable. The current clang calling convention lowering emits raw values, including aggregates into the function argument list, since using byval would not make sense. This has some unfortunate consequences for the optimizer. In the aggregate case, we end up with an aggregate store to alloca, which both SROA and instcombine turn into a store of each aggregate field. The optimizer never pieces this back together to see that this is really just a copy from constant memory, so we end up stuck with expensive stack usage. This also means the backend dictates the alignment of arguments, and arbitrarily picks the LLVM IR ABI type alignment. By allowing an explicit alignment, frontends can make better decisions. For example, there's real no advantage to an aligment higher than 4, so a frontend could choose to compact the argument layout. Similarly, there is a high penalty to using an alignment lower than 4, so a frontend could opt into more padding for small arguments. Another design consideration is when it is appropriate to expose the fact that these arguments are all really passed in adjacent memory. Currently we have a late IR optimization pass in codegen to rewrite the kernel argument values into explicit loads to enable vectorization. In most programs, unrelated argument loads can be merged together. However, exposing this property directly from the frontend has some disadvantages. We still need a way to track the original argument sizes and alignments to report to the driver. I find using some side-channel, metadata mechanism to track this unappealing. If the kernel arguments were exposed as a single buffer to begin with, alias analysis would be unaware that the padding bits betewen arguments are meaningless. Another family of problems is there are still some gaps in replacing all of the available parameter attributes with metadata equivalents once lowered to loads. The immediate plan is to start using this new attribute to handle all aggregate argumets for kernels. Long term, it makes sense to migrate all kernel arguments, including scalars, to be passed indirectly in the same manner. Additional context is in D79744.
2020-06-06 04:58:47 +08:00
if (!ByRefType)
ByRefType = B.ByRefType;
Add IR constructs for preallocated (inalloca replacement) Add llvm.call.preallocated.{setup,arg} instrinsics. Add "preallocated" operand bundle which takes a token produced by llvm.call.preallocated.setup. Add "preallocated" parameter attribute, which is like byval but without the copy. Verifier changes for these IR constructs. See https://github.com/rnk/llvm-project/blob/call-setup-docs/llvm/docs/CallSetup.md Subscribers: hiraditya, jdoerfert, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D74651
2020-02-15 06:16:53 +08:00
if (!PreallocatedType)
PreallocatedType = B.PreallocatedType;
Turn the enum attributes DenseSet in AttrBuilder into a set of bits. Avoids malloc and is a lot denser. We lose iteration over target independent attributes, but that's a strange interface anyways and didn't have any users outside of AttrBuilder. llvm-svn: 175370
2013-02-17 03:13:18 +08:00
Attrs |= B.Attrs;
Add methods to merge an AttrBuilder into another builder. This is useful when parsing an object that references multiple attribute groups. N.B. If both builders have alignments specified, then they should match! llvm-svn: 174480
2013-02-06 09:16:00 +08:00
AttrBuilder::merge/remove - use const& for iterator values in for-range loops. Noticed by clang-tidy performance-for-range-copy warning.
2020-07-01 01:03:16 +08:00
for (const auto &I : B.td_attrs())
Add remove method to operate on AttrBuilder instead of AttributeSet. Prior to this change we would have to construct a temporary AttributeSet (which isn't temporary at all given that its allocated on the context), just to contain the attributes in the builder, then call remove on that. Now we can just remove any attributes from the (lightweight and really temporary) builder itself. Will be used in a future commit to remove some temporary attributes sets. llvm-svn: 236666
2015-05-07 07:19:43 +08:00
TargetDepAttrs[I.first] = I.second;
Add methods to merge an AttrBuilder into another builder. This is useful when parsing an object that references multiple attribute groups. N.B. If both builders have alignments specified, then they should match! llvm-svn: 174480
2013-02-06 09:16:00 +08:00
return *this;
}
Add remove method to operate on AttrBuilder instead of AttributeSet. Prior to this change we would have to construct a temporary AttributeSet (which isn't temporary at all given that its allocated on the context), just to contain the attributes in the builder, then call remove on that. Now we can just remove any attributes from the (lightweight and really temporary) builder itself. Will be used in a future commit to remove some temporary attributes sets. llvm-svn: 236666
2015-05-07 07:19:43 +08:00
AttrBuilder &AttrBuilder::remove(const AttrBuilder &B) {
// FIXME: What if both have alignments, but they don't match?!
if (B.Alignment)
[LLVM][Alignment] Introduce Alignment In Attributes Summary: This is patch is part of a serie to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: jfb Subscribers: hiraditya, dexonsmith, llvm-commits, courbet Tags: #llvm Differential Revision: https://reviews.llvm.org/D65742 llvm-svn: 368002
2019-08-06 17:16:33 +08:00
Alignment.reset();
Add remove method to operate on AttrBuilder instead of AttributeSet. Prior to this change we would have to construct a temporary AttributeSet (which isn't temporary at all given that its allocated on the context), just to contain the attributes in the builder, then call remove on that. Now we can just remove any attributes from the (lightweight and really temporary) builder itself. Will be used in a future commit to remove some temporary attributes sets. llvm-svn: 236666
2015-05-07 07:19:43 +08:00
if (B.StackAlignment)
[LLVM][Alignment] Introduce Alignment In Attributes Summary: This is patch is part of a serie to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: jfb Subscribers: hiraditya, dexonsmith, llvm-commits, courbet Tags: #llvm Differential Revision: https://reviews.llvm.org/D65742 llvm-svn: 368002
2019-08-06 17:16:33 +08:00
StackAlignment.reset();
Add remove method to operate on AttrBuilder instead of AttributeSet. Prior to this change we would have to construct a temporary AttributeSet (which isn't temporary at all given that its allocated on the context), just to contain the attributes in the builder, then call remove on that. Now we can just remove any attributes from the (lightweight and really temporary) builder itself. Will be used in a future commit to remove some temporary attributes sets. llvm-svn: 236666
2015-05-07 07:19:43 +08:00
if (B.DerefBytes)
DerefBytes = 0;
if (B.DerefOrNullBytes)
DerefOrNullBytes = 0;
Add the allocsize attribute to LLVM. `allocsize` is a function attribute that allows users to request that LLVM treat arbitrary functions as allocation functions. This patch makes LLVM accept the `allocsize` attribute, and makes `@llvm.objectsize` recognize said attribute. The review for this was split into two patches for ease of reviewing: D18974 and D14933. As promised on the revisions, I'm landing both patches as a single commit. Differential Revision: http://reviews.llvm.org/D14933 llvm-svn: 266032
2016-04-12 09:05:35 +08:00
if (B.AllocSizeArgs)
AllocSizeArgs = 0;
Reapply: IR: add optional type to 'byval' function parameters When we switch to opaque pointer types we will need some way to describe how many bytes a 'byval' parameter should occupy on the stack. This adds a (for now) optional extra type parameter. If present, the type must match the pointee type of the argument. The original commit did not remap byval types when linking modules, which broke LTO. This version fixes that. Note to front-end maintainers: if this causes test failures, it's probably because the "byval" attribute is printed after attributes without any parameter after this change. llvm-svn: 362128
2019-05-31 02:48:23 +08:00
if (B.ByValType)
ByValType = nullptr;
Reapply "OpaquePtr: Add type to sret attribute" This reverts commit eb9f7c28e5fe6d75fed3587023e17f2997c8024b. Previously this was incorrectly handling linking of the contained type, so this merges the fixes from D88973.
2020-09-29 21:33:55 +08:00
if (B.StructRetType)
StructRetType = nullptr;
IR: Define byref parameter attribute This allows tracking the in-memory type of a pointer argument to a function for ABI purposes. This is essentially a stripped down version of byval to remove some of the stack-copy implications in its definition. This includes the base IR changes, and some tests for places where it should be treated similarly to byval. Codegen support will be in a future patch. My original attempt at solving some of these problems was to repurpose byval with a different address space from the stack. However, it is technically permitted for the callee to introduce a write to the argument, although nothing does this in reality. There is also talk of removing and replacing the byval attribute, so a new attribute would need to take its place anyway. This is intended avoid some optimization issues with the current handling of aggregate arguments, as well as fixes inflexibilty in how frontends can specify the kernel ABI. The most honest representation of the amdgpu_kernel convention is to expose all kernel arguments as loads from constant memory. Today, these are raw, SSA Argument values and codegen is responsible for turning these into loads. Background: There currently isn't a satisfactory way to represent how arguments for the amdgpu_kernel calling convention are passed. In reality, arguments are passed in a single, flat, constant memory buffer implicitly passed to the function. It is also illegal to call this function in the IR, and this is only ever invoked by a driver of some kind. It does not make sense to have a stack passed parameter in this context as is implied by byval. It is never valid to write to the kernel arguments, as this would corrupt the inputs seen by other dispatches of the kernel. These argumets are also not in the same address space as the stack, so a copy is needed to an alloca. From a source C-like language, the kernel parameters are invisible. Semantically, a copy is always required from the constant argument memory to a mutable variable. The current clang calling convention lowering emits raw values, including aggregates into the function argument list, since using byval would not make sense. This has some unfortunate consequences for the optimizer. In the aggregate case, we end up with an aggregate store to alloca, which both SROA and instcombine turn into a store of each aggregate field. The optimizer never pieces this back together to see that this is really just a copy from constant memory, so we end up stuck with expensive stack usage. This also means the backend dictates the alignment of arguments, and arbitrarily picks the LLVM IR ABI type alignment. By allowing an explicit alignment, frontends can make better decisions. For example, there's real no advantage to an aligment higher than 4, so a frontend could choose to compact the argument layout. Similarly, there is a high penalty to using an alignment lower than 4, so a frontend could opt into more padding for small arguments. Another design consideration is when it is appropriate to expose the fact that these arguments are all really passed in adjacent memory. Currently we have a late IR optimization pass in codegen to rewrite the kernel argument values into explicit loads to enable vectorization. In most programs, unrelated argument loads can be merged together. However, exposing this property directly from the frontend has some disadvantages. We still need a way to track the original argument sizes and alignments to report to the driver. I find using some side-channel, metadata mechanism to track this unappealing. If the kernel arguments were exposed as a single buffer to begin with, alias analysis would be unaware that the padding bits betewen arguments are meaningless. Another family of problems is there are still some gaps in replacing all of the available parameter attributes with metadata equivalents once lowered to loads. The immediate plan is to start using this new attribute to handle all aggregate argumets for kernels. Long term, it makes sense to migrate all kernel arguments, including scalars, to be passed indirectly in the same manner. Additional context is in D79744.
2020-06-06 04:58:47 +08:00
if (B.ByRefType)
ByRefType = nullptr;
Add IR constructs for preallocated (inalloca replacement) Add llvm.call.preallocated.{setup,arg} instrinsics. Add "preallocated" operand bundle which takes a token produced by llvm.call.preallocated.setup. Add "preallocated" parameter attribute, which is like byval but without the copy. Verifier changes for these IR constructs. See https://github.com/rnk/llvm-project/blob/call-setup-docs/llvm/docs/CallSetup.md Subscribers: hiraditya, jdoerfert, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D74651
2020-02-15 06:16:53 +08:00
if (B.PreallocatedType)
PreallocatedType = nullptr;
Add remove method to operate on AttrBuilder instead of AttributeSet. Prior to this change we would have to construct a temporary AttributeSet (which isn't temporary at all given that its allocated on the context), just to contain the attributes in the builder, then call remove on that. Now we can just remove any attributes from the (lightweight and really temporary) builder itself. Will be used in a future commit to remove some temporary attributes sets. llvm-svn: 236666
2015-05-07 07:19:43 +08:00
Attrs &= ~B.Attrs;
AttrBuilder::merge/remove - use const& for iterator values in for-range loops. Noticed by clang-tidy performance-for-range-copy warning.
2020-07-01 01:03:16 +08:00
for (const auto &I : B.td_attrs())
Add remove method to operate on AttrBuilder instead of AttributeSet. Prior to this change we would have to construct a temporary AttributeSet (which isn't temporary at all given that its allocated on the context), just to contain the attributes in the builder, then call remove on that. Now we can just remove any attributes from the (lightweight and really temporary) builder itself. Will be used in a future commit to remove some temporary attributes sets. llvm-svn: 236666
2015-05-07 07:19:43 +08:00
TargetDepAttrs.erase(I.first);
return *this;
}
bool AttrBuilder::overlaps(const AttrBuilder &B) const {
// First check if any of the target independent attributes overlap.
if ((Attrs & B.Attrs).any())
return true;
// Then check if any target dependent ones do.
Use const-ref in range-loop for to avoid copying pairs of std::string No reason to create temporaries. Differential Revision: https://reviews.llvm.org/D29871 Patch by sergio.martins! llvm-svn: 295807
2017-02-22 14:34:04 +08:00
for (const auto &I : td_attrs())
Add remove method to operate on AttrBuilder instead of AttributeSet. Prior to this change we would have to construct a temporary AttributeSet (which isn't temporary at all given that its allocated on the context), just to contain the attributes in the builder, then call remove on that. Now we can just remove any attributes from the (lightweight and really temporary) builder itself. Will be used in a future commit to remove some temporary attributes sets. llvm-svn: 236666
2015-05-07 07:19:43 +08:00
if (B.contains(I.first))
return true;
return false;
}
Add a 'StringRef' version of hasAttribute. Fix the 'operator==' and 'hasAttributes' queries to take into account target-dependent attributes. llvm-svn: 174481
2013-02-06 09:33:42 +08:00
bool AttrBuilder::contains(StringRef A) const {
return TargetDepAttrs.find(A) != TargetDepAttrs.end();
}
Reorder some functions and add comments. No functionality change. llvm-svn: 173733
2013-01-29 08:34:06 +08:00
bool AttrBuilder::hasAttributes() const {
Futureproof AttrBuild if we ever have more than 64 attr enum values. Currently we're at 34. Bitset should compile into virtually the same code as uint64_t here. llvm-svn: 175437
2013-02-18 20:09:51 +08:00
return !Attrs.none() || !TargetDepAttrs.empty();
Reorder some functions and add comments. No functionality change. llvm-svn: 173733
2013-01-29 08:34:06 +08:00
}
Use Argument::hasAttribute and AttributeList::ReturnIndex more This eliminates many extra 'Idx' induction variables in loops over arguments in CodeGen/ and Target/. It also reduces the number of places where we assume that ReturnIndex is 0 and that we should add one to argument numbers to get the corresponding attribute list index. NFC llvm-svn: 301666
2017-04-29 02:37:16 +08:00
bool AttrBuilder::hasAttributes(AttributeList AL, uint64_t Index) const {
AttributeSet AS = AL.getAttributes(Index);
Use the AttributeSet's iterators. Use the AttributeSet's iterators in AttrBuilder::hasAttributes() when determining of the intersection of the AttrBuilder and AttributeSet is non-null. llvm-svn: 174250
2013-02-02 08:42:06 +08:00
[IR] Use a reference in a range-based for This avoids unneeded copies when using a range-based for loops. This avoids new warnings due to D68912 adds -Wrange-loop-analysis to -Wall. Differential Revision: https://reviews.llvm.org/D70870
2019-12-18 04:57:58 +08:00
for (const auto &Attr : AS) {
Rename AlignAttribute to IntAttribute Currently the only kind of integer IR attributes that we have are alignment attributes, and so the attribute kind that takes an integer parameter is called AlignAttr, but that will change (we'll soon be adding a dereferenceable attribute that also takes an integer value). Accordingly, rename AlignAttribute to IntAttribute (class names, enums, etc.). No functionality change intended. llvm-svn: 213352
2014-07-18 14:51:55 +08:00
if (Attr.isEnumAttribute() || Attr.isIntAttribute()) {
Use Argument::hasAttribute and AttributeList::ReturnIndex more This eliminates many extra 'Idx' induction variables in loops over arguments in CodeGen/ and Target/. It also reduces the number of places where we assume that ReturnIndex is 0 and that we should add one to argument numbers to get the corresponding attribute list index. NFC llvm-svn: 301666
2017-04-29 02:37:16 +08:00
if (contains(Attr.getKindAsEnum()))
Support string attributes in the AttrBuilder. llvm-svn: 174948
2013-02-12 15:56:49 +08:00
return true;
} else {
assert(Attr.isStringAttribute() && "Invalid attribute kind!");
Use Argument::hasAttribute and AttributeList::ReturnIndex more This eliminates many extra 'Idx' induction variables in loops over arguments in CodeGen/ and Target/. It also reduces the number of places where we assume that ReturnIndex is 0 and that we should add one to argument numbers to get the corresponding attribute list index. NFC llvm-svn: 301666
2017-04-29 02:37:16 +08:00
return contains(Attr.getKindAsString());
Support string attributes in the AttrBuilder. llvm-svn: 174948
2013-02-12 15:56:49 +08:00
}
}
Use the AttributeSet's iterators. Use the AttributeSet's iterators in AttrBuilder::hasAttributes() when determining of the intersection of the AttrBuilder and AttributeSet is non-null. llvm-svn: 174250
2013-02-02 08:42:06 +08:00
return false;
Reorder some functions and add comments. No functionality change. llvm-svn: 173733
2013-01-29 08:34:06 +08:00
}
bool AttrBuilder::hasAlignmentAttr() const {
return Alignment != 0;
}
Make LLVM build in C++20 mode Part of the <=> changes in C++20 make certain patterns of writing equality operators ambiguous with themselves (sorry!). This patch goes through and adjusts all the comparison operators such that they should work in both C++17 and C++20 modes. It also makes two other small C++20-specific changes (adding a constructor to a type that cases to be an aggregate, and adding casts from u8 literals which no longer have type const char*). There were four categories of errors that this review fixes. Here are canonical examples of them, ordered from most to least common: // 1) Missing const namespace missing_const { struct A { #ifndef FIXED bool operator==(A const&); #else bool operator==(A const&) const; #endif }; bool a = A{} == A{}; // error } // 2) Type mismatch on CRTP namespace crtp_mismatch { template <typename Derived> struct Base { #ifndef FIXED bool operator==(Derived const&) const; #else // in one case changed to taking Base const& friend bool operator==(Derived const&, Derived const&); #endif }; struct D : Base<D> { }; bool b = D{} == D{}; // error } // 3) iterator/const_iterator with only mixed comparison namespace iter_const_iter { template <bool Const> struct iterator { using const_iterator = iterator<true>; iterator(); template <bool B, std::enable_if_t<(Const && !B), int> = 0> iterator(iterator<B> const&); #ifndef FIXED bool operator==(const_iterator const&) const; #else friend bool operator==(iterator const&, iterator const&); #endif }; bool c = iterator<false>{} == iterator<false>{} // error || iterator<false>{} == iterator<true>{} || iterator<true>{} == iterator<false>{} || iterator<true>{} == iterator<true>{}; } // 4) Same-type comparison but only have mixed-type operator namespace ambiguous_choice { enum Color { Red }; struct C { C(); C(Color); operator Color() const; bool operator==(Color) const; friend bool operator==(C, C); }; bool c = C{} == C{}; // error bool d = C{} == Red; } Differential revision: https://reviews.llvm.org/D78938
2020-12-17 18:41:35 +08:00
bool AttrBuilder::operator==(const AttrBuilder &B) const {
Turn the enum attributes DenseSet in AttrBuilder into a set of bits. Avoids malloc and is a lot denser. We lose iteration over target independent attributes, but that's a strange interface anyways and didn't have any users outside of AttrBuilder. llvm-svn: 175370
2013-02-17 03:13:18 +08:00
if (Attrs != B.Attrs)
return false;
Add a 'StringRef' version of hasAttribute. Fix the 'operator==' and 'hasAttributes' queries to take into account target-dependent attributes. llvm-svn: 174481
2013-02-06 09:33:42 +08:00
[IR] Use range-based for loops (NFC)
2021-02-28 02:09:25 +08:00
for (const auto &TDA : TargetDepAttrs)
if (B.TargetDepAttrs.find(TDA.first) == B.TargetDepAttrs.end())
Add a 'StringRef' version of hasAttribute. Fix the 'operator==' and 'hasAttributes' queries to take into account target-dependent attributes. llvm-svn: 174481
2013-02-06 09:33:42 +08:00
return false;
Add a dereferenceable attribute This attribute indicates that the parameter or return pointer is dereferenceable. Practically speaking, loads from such a pointer within the associated byte range are safe to speculatively execute. Such pointer parameters are common in source languages (C++ references, for example). llvm-svn: 213385
2014-07-18 23:51:28 +08:00
return Alignment == B.Alignment && StackAlignment == B.StackAlignment &&
Add IR constructs for preallocated (inalloca replacement) Add llvm.call.preallocated.{setup,arg} instrinsics. Add "preallocated" operand bundle which takes a token produced by llvm.call.preallocated.setup. Add "preallocated" parameter attribute, which is like byval but without the copy. Verifier changes for these IR constructs. See https://github.com/rnk/llvm-project/blob/call-setup-docs/llvm/docs/CallSetup.md Subscribers: hiraditya, jdoerfert, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D74651
2020-02-15 06:16:53 +08:00
DerefBytes == B.DerefBytes && ByValType == B.ByValType &&
Reapply "OpaquePtr: Add type to sret attribute" This reverts commit eb9f7c28e5fe6d75fed3587023e17f2997c8024b. Previously this was incorrectly handling linking of the contained type, so this merges the fixes from D88973.
2020-09-29 21:33:55 +08:00
StructRetType == B.StructRetType && ByRefType == B.ByRefType &&
PreallocatedType == B.PreallocatedType;
Reorder some functions and add comments. No functionality change. llvm-svn: 173733
2013-01-29 08:34:06 +08:00
}
Remove some introspection functions. The 'getSlot' function and its ilk allow introspection into the AttributeSet class. However, that class should be opaque. Allow access through accessor methods instead. llvm-svn: 173522
2013-01-26 07:09:36 +08:00
//===----------------------------------------------------------------------===//
// AttributeFuncs Function Defintions
//===----------------------------------------------------------------------===//
Remove \brief commands from doxygen comments. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46290 llvm-svn: 331272
2018-05-01 23:54:18 +08:00
/// Which attributes cannot be applied to a type.
De-constify pointers to Type since they can't be modified. NFC This was already done in most places a while ago. This just fixes the ones that crept in over time. llvm-svn: 243842
2015-08-02 06:20:21 +08:00
AttrBuilder AttributeFuncs::typeIncompatible(Type *Ty) {
Remove some introspection functions. The 'getSlot' function and its ilk allow introspection into the AttributeSet class. However, that class should be opaque. Allow access through accessor methods instead. llvm-svn: 173522
2013-01-26 07:09:36 +08:00
AttrBuilder Incompatible;
if (!Ty->isIntegerTy())
// Attribute that only apply to integers.
Incompatible.addAttribute(Attribute::SExt)
.addAttribute(Attribute::ZExt);
if (!Ty->isPointerTy())
// Attribute that only apply to pointers.
Add IR constructs for preallocated (inalloca replacement) Add llvm.call.preallocated.{setup,arg} instrinsics. Add "preallocated" operand bundle which takes a token produced by llvm.call.preallocated.setup. Add "preallocated" parameter attribute, which is like byval but without the copy. Verifier changes for these IR constructs. See https://github.com/rnk/llvm-project/blob/call-setup-docs/llvm/docs/CallSetup.md Subscribers: hiraditya, jdoerfert, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D74651
2020-02-15 06:16:53 +08:00
Incompatible.addAttribute(Attribute::Nest)
.addAttribute(Attribute::NoAlias)
.addAttribute(Attribute::NoCapture)
.addAttribute(Attribute::NonNull)
[AttributeFuncs] Consider `align` in `typeIncompatible` Alignment attributes need to be dropped for non-pointer values. This also introduces a check into the verifier to ensure you don't use `align` on anything but a pointer. Test needed to be adjusted accordingly. Reviewed By: fhahn Differential Revision: https://reviews.llvm.org/D87304
2020-09-08 23:10:36 +08:00
.addAlignmentAttr(1) // the int here is ignored
Add IR constructs for preallocated (inalloca replacement) Add llvm.call.preallocated.{setup,arg} instrinsics. Add "preallocated" operand bundle which takes a token produced by llvm.call.preallocated.setup. Add "preallocated" parameter attribute, which is like byval but without the copy. Verifier changes for these IR constructs. See https://github.com/rnk/llvm-project/blob/call-setup-docs/llvm/docs/CallSetup.md Subscribers: hiraditya, jdoerfert, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D74651
2020-02-15 06:16:53 +08:00
.addDereferenceableAttr(1) // the int here is ignored
.addDereferenceableOrNullAttr(1) // the int here is ignored
.addAttribute(Attribute::ReadNone)
.addAttribute(Attribute::ReadOnly)
.addAttribute(Attribute::InAlloca)
.addPreallocatedAttr(Ty)
IR: Define byref parameter attribute This allows tracking the in-memory type of a pointer argument to a function for ABI purposes. This is essentially a stripped down version of byval to remove some of the stack-copy implications in its definition. This includes the base IR changes, and some tests for places where it should be treated similarly to byval. Codegen support will be in a future patch. My original attempt at solving some of these problems was to repurpose byval with a different address space from the stack. However, it is technically permitted for the callee to introduce a write to the argument, although nothing does this in reality. There is also talk of removing and replacing the byval attribute, so a new attribute would need to take its place anyway. This is intended avoid some optimization issues with the current handling of aggregate arguments, as well as fixes inflexibilty in how frontends can specify the kernel ABI. The most honest representation of the amdgpu_kernel convention is to expose all kernel arguments as loads from constant memory. Today, these are raw, SSA Argument values and codegen is responsible for turning these into loads. Background: There currently isn't a satisfactory way to represent how arguments for the amdgpu_kernel calling convention are passed. In reality, arguments are passed in a single, flat, constant memory buffer implicitly passed to the function. It is also illegal to call this function in the IR, and this is only ever invoked by a driver of some kind. It does not make sense to have a stack passed parameter in this context as is implied by byval. It is never valid to write to the kernel arguments, as this would corrupt the inputs seen by other dispatches of the kernel. These argumets are also not in the same address space as the stack, so a copy is needed to an alloca. From a source C-like language, the kernel parameters are invisible. Semantically, a copy is always required from the constant argument memory to a mutable variable. The current clang calling convention lowering emits raw values, including aggregates into the function argument list, since using byval would not make sense. This has some unfortunate consequences for the optimizer. In the aggregate case, we end up with an aggregate store to alloca, which both SROA and instcombine turn into a store of each aggregate field. The optimizer never pieces this back together to see that this is really just a copy from constant memory, so we end up stuck with expensive stack usage. This also means the backend dictates the alignment of arguments, and arbitrarily picks the LLVM IR ABI type alignment. By allowing an explicit alignment, frontends can make better decisions. For example, there's real no advantage to an aligment higher than 4, so a frontend could choose to compact the argument layout. Similarly, there is a high penalty to using an alignment lower than 4, so a frontend could opt into more padding for small arguments. Another design consideration is when it is appropriate to expose the fact that these arguments are all really passed in adjacent memory. Currently we have a late IR optimization pass in codegen to rewrite the kernel argument values into explicit loads to enable vectorization. In most programs, unrelated argument loads can be merged together. However, exposing this property directly from the frontend has some disadvantages. We still need a way to track the original argument sizes and alignments to report to the driver. I find using some side-channel, metadata mechanism to track this unappealing. If the kernel arguments were exposed as a single buffer to begin with, alias analysis would be unaware that the padding bits betewen arguments are meaningless. Another family of problems is there are still some gaps in replacing all of the available parameter attributes with metadata equivalents once lowered to loads. The immediate plan is to start using this new attribute to handle all aggregate argumets for kernels. Long term, it makes sense to migrate all kernel arguments, including scalars, to be passed indirectly in the same manner. Additional context is in D79744.
2020-06-06 04:58:47 +08:00
.addByValAttr(Ty)
Reapply "OpaquePtr: Add type to sret attribute" This reverts commit eb9f7c28e5fe6d75fed3587023e17f2997c8024b. Previously this was incorrectly handling linking of the contained type, so this merges the fixes from D88973.
2020-09-29 21:33:55 +08:00
.addStructRetAttr(Ty)
IR: Define byref parameter attribute This allows tracking the in-memory type of a pointer argument to a function for ABI purposes. This is essentially a stripped down version of byval to remove some of the stack-copy implications in its definition. This includes the base IR changes, and some tests for places where it should be treated similarly to byval. Codegen support will be in a future patch. My original attempt at solving some of these problems was to repurpose byval with a different address space from the stack. However, it is technically permitted for the callee to introduce a write to the argument, although nothing does this in reality. There is also talk of removing and replacing the byval attribute, so a new attribute would need to take its place anyway. This is intended avoid some optimization issues with the current handling of aggregate arguments, as well as fixes inflexibilty in how frontends can specify the kernel ABI. The most honest representation of the amdgpu_kernel convention is to expose all kernel arguments as loads from constant memory. Today, these are raw, SSA Argument values and codegen is responsible for turning these into loads. Background: There currently isn't a satisfactory way to represent how arguments for the amdgpu_kernel calling convention are passed. In reality, arguments are passed in a single, flat, constant memory buffer implicitly passed to the function. It is also illegal to call this function in the IR, and this is only ever invoked by a driver of some kind. It does not make sense to have a stack passed parameter in this context as is implied by byval. It is never valid to write to the kernel arguments, as this would corrupt the inputs seen by other dispatches of the kernel. These argumets are also not in the same address space as the stack, so a copy is needed to an alloca. From a source C-like language, the kernel parameters are invisible. Semantically, a copy is always required from the constant argument memory to a mutable variable. The current clang calling convention lowering emits raw values, including aggregates into the function argument list, since using byval would not make sense. This has some unfortunate consequences for the optimizer. In the aggregate case, we end up with an aggregate store to alloca, which both SROA and instcombine turn into a store of each aggregate field. The optimizer never pieces this back together to see that this is really just a copy from constant memory, so we end up stuck with expensive stack usage. This also means the backend dictates the alignment of arguments, and arbitrarily picks the LLVM IR ABI type alignment. By allowing an explicit alignment, frontends can make better decisions. For example, there's real no advantage to an aligment higher than 4, so a frontend could choose to compact the argument layout. Similarly, there is a high penalty to using an alignment lower than 4, so a frontend could opt into more padding for small arguments. Another design consideration is when it is appropriate to expose the fact that these arguments are all really passed in adjacent memory. Currently we have a late IR optimization pass in codegen to rewrite the kernel argument values into explicit loads to enable vectorization. In most programs, unrelated argument loads can be merged together. However, exposing this property directly from the frontend has some disadvantages. We still need a way to track the original argument sizes and alignments to report to the driver. I find using some side-channel, metadata mechanism to track this unappealing. If the kernel arguments were exposed as a single buffer to begin with, alias analysis would be unaware that the padding bits betewen arguments are meaningless. Another family of problems is there are still some gaps in replacing all of the available parameter attributes with metadata equivalents once lowered to loads. The immediate plan is to start using this new attribute to handle all aggregate argumets for kernels. Long term, it makes sense to migrate all kernel arguments, including scalars, to be passed indirectly in the same manner. Additional context is in D79744.
2020-06-06 04:58:47 +08:00
.addByRefAttr(Ty);
Remove some introspection functions. The 'getSlot' function and its ilk allow introspection into the AttributeSet class. However, that class should be opaque. Allow access through accessor methods instead. llvm-svn: 173522
2013-01-26 07:09:36 +08:00
[AttributeFuncs] Consider `noundef` in `typeIncompatible` Drop `noundef` for return values that are replaced by void and make it illegal to put `noundef` on a void value. Reviewed By: fhahn Differential Revision: https://reviews.llvm.org/D87306
2020-09-08 23:13:11 +08:00
// Some attributes can apply to all "values" but there are no `void` values.
if (Ty->isVoidTy())
Incompatible.addAttribute(Attribute::NoUndef);
Change typeIncompatible to return an AttrBuilder instead of new-ing an AttributeSet. This makes use of the new API which can remove attributes from a set given a builder. This is much faster than creating a temporary set and reduces llc time by about 0.3% which was all spent creating temporary attributes sets on the context. llvm-svn: 236668
2015-05-07 07:19:56 +08:00
return Incompatible;
Remove some introspection functions. The 'getSlot' function and its ilk allow introspection into the AttributeSet class. However, that class should be opaque. Allow access through accessor methods instead. llvm-svn: 173522
2013-01-26 07:09:36 +08:00
}
Provide a way to specify inliner's attribute compatibility and merging. This reapplies r256277 with two changes: - In emitFnAttrCompatCheck, change FuncName's type to std::string to fix a use-after-free bug. - Remove an unnecessary install-local target in lib/IR/Makefile. Original commit message for r252949: Provide a way to specify inliner's attribute compatibility and merging rules using table-gen. NFC. This commit adds new classes CompatRule and MergeRule to Attributes.td, which are used to generate code to check attribute compatibility and merge attributes of the caller and callee. rdar://problem/19836465 llvm-svn: 256304
2015-12-23 07:57:37 +08:00
template<typename AttrClass>
static bool isEqual(const Function &Caller, const Function &Callee) {
return Caller.getFnAttribute(AttrClass::getKind()) ==
Callee.getFnAttribute(AttrClass::getKind());
}
Remove \brief commands from doxygen comments. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46290 llvm-svn: 331272
2018-05-01 23:54:18 +08:00
/// Compute the logical AND of the attributes of the caller and the
Provide a way to specify inliner's attribute compatibility and merging. This reapplies r256277 with two changes: - In emitFnAttrCompatCheck, change FuncName's type to std::string to fix a use-after-free bug. - Remove an unnecessary install-local target in lib/IR/Makefile. Original commit message for r252949: Provide a way to specify inliner's attribute compatibility and merging rules using table-gen. NFC. This commit adds new classes CompatRule and MergeRule to Attributes.td, which are used to generate code to check attribute compatibility and merge attributes of the caller and callee. rdar://problem/19836465 llvm-svn: 256304
2015-12-23 07:57:37 +08:00
/// callee.
///
/// This function sets the caller's attribute to false if the callee's attribute
/// is false.
template<typename AttrClass>
static void setAND(Function &Caller, const Function &Callee) {
if (AttrClass::isSet(Caller, AttrClass::getKind()) &&
!AttrClass::isSet(Callee, AttrClass::getKind()))
AttrClass::set(Caller, AttrClass::getKind(), false);
}
Remove \brief commands from doxygen comments. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46290 llvm-svn: 331272
2018-05-01 23:54:18 +08:00
/// Compute the logical OR of the attributes of the caller and the
Provide a way to specify inliner's attribute compatibility and merging. This reapplies r256277 with two changes: - In emitFnAttrCompatCheck, change FuncName's type to std::string to fix a use-after-free bug. - Remove an unnecessary install-local target in lib/IR/Makefile. Original commit message for r252949: Provide a way to specify inliner's attribute compatibility and merging rules using table-gen. NFC. This commit adds new classes CompatRule and MergeRule to Attributes.td, which are used to generate code to check attribute compatibility and merge attributes of the caller and callee. rdar://problem/19836465 llvm-svn: 256304
2015-12-23 07:57:37 +08:00
/// callee.
///
/// This function sets the caller's attribute to true if the callee's attribute
/// is true.
template<typename AttrClass>
static void setOR(Function &Caller, const Function &Callee) {
if (!AttrClass::isSet(Caller, AttrClass::getKind()) &&
AttrClass::isSet(Callee, AttrClass::getKind()))
AttrClass::set(Caller, AttrClass::getKind(), true);
}
Remove \brief commands from doxygen comments. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46290 llvm-svn: 331272
2018-05-01 23:54:18 +08:00
/// If the inlined function had a higher stack protection level than the
Provide a way to specify inliner's attribute compatibility and merging. This reapplies r256277 with two changes: - In emitFnAttrCompatCheck, change FuncName's type to std::string to fix a use-after-free bug. - Remove an unnecessary install-local target in lib/IR/Makefile. Original commit message for r252949: Provide a way to specify inliner's attribute compatibility and merging rules using table-gen. NFC. This commit adds new classes CompatRule and MergeRule to Attributes.td, which are used to generate code to check attribute compatibility and merge attributes of the caller and callee. rdar://problem/19836465 llvm-svn: 256304
2015-12-23 07:57:37 +08:00
/// calling function, then bump up the caller's stack protection level.
static void adjustCallerSSPLevel(Function &Caller, const Function &Callee) {
[Inline] prevent inlining on stack protector mismatch It's common for code that manipulates the stack via inline assembly or that has to set up its own stack canary (such as the Linux kernel) would like to avoid stack protectors in certain functions. In this case, we've been bitten by numerous bugs where a callee with a stack protector is inlined into an attribute((no_stack_protector)) caller, which generally breaks the caller's assumptions about not having a stack protector. LTO exacerbates the issue. While developers can avoid this by putting all no_stack_protector functions in one translation unit together and compiling those with -fno-stack-protector, it's generally not very ergonomic or as ergonomic as a function attribute, and still doesn't work for LTO. See also: https://lore.kernel.org/linux-pm/20200915172658.1432732-1-rkir@google.com/ https://lore.kernel.org/lkml/20200918201436.2932360-30-samitolvanen@google.com/T/#u SSP attributes can be ordered by strength. Weakest to strongest, they are: ssp, sspstrong, sspreq. Callees with differing SSP attributes may be inlined into each other, and the strongest attribute will be applied to the caller. (No change) After this change: * A callee with no SSP attributes will no longer be inlined into a caller with SSP attributes. * The reverse is also true: a callee with an SSP attribute will not be inlined into a caller with no SSP attributes. * The alwaysinline attribute overrides these rules. Functions that get synthesized by the compiler may not get inlined as a result if they are not created with the same stack protector function attribute as their callers. Alternative approach to https://reviews.llvm.org/D87956. Fixes pr/47479. Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed By: rnk, MaskRay Differential Revision: https://reviews.llvm.org/D91816
2020-12-03 02:44:35 +08:00
#ifndef NDEBUG
if (!Callee.hasFnAttribute(Attribute::AlwaysInline)) {
assert(!(!Callee.hasStackProtectorFnAttr() &&
Caller.hasStackProtectorFnAttr()) &&
"stack protected caller but callee requested no stack protector");
assert(!(!Caller.hasStackProtectorFnAttr() &&
Callee.hasStackProtectorFnAttr()) &&
"stack protected callee but caller requested no stack protector");
}
#endif
Provide a way to specify inliner's attribute compatibility and merging. This reapplies r256277 with two changes: - In emitFnAttrCompatCheck, change FuncName's type to std::string to fix a use-after-free bug. - Remove an unnecessary install-local target in lib/IR/Makefile. Original commit message for r252949: Provide a way to specify inliner's attribute compatibility and merging rules using table-gen. NFC. This commit adds new classes CompatRule and MergeRule to Attributes.td, which are used to generate code to check attribute compatibility and merge attributes of the caller and callee. rdar://problem/19836465 llvm-svn: 256304
2015-12-23 07:57:37 +08:00
// If upgrading the SSP attribute, clear out the old SSP Attributes first.
Revert "[IR] add fn attr for no_stack_protector; prevent inlining on mismatch" This reverts commit b7926ce6d7a83cdf70c68d82bc3389c04009b841. Going with a simpler approach.
2020-11-18 09:17:44 +08:00
// Having multiple SSP attributes doesn't actually hurt, but it adds useless
// clutter to the IR.
Re-land r301697 "[IR] Make add/remove Attributes use AttrBuilder instead of AttributeList" This time, I fixed, built, and tested clang. This reverts r301712. llvm-svn: 301981
2017-05-03 06:07:37 +08:00
AttrBuilder OldSSPAttr;
OldSSPAttr.addAttribute(Attribute::StackProtect)
.addAttribute(Attribute::StackProtectStrong)
.addAttribute(Attribute::StackProtectReq);
Provide a way to specify inliner's attribute compatibility and merging. This reapplies r256277 with two changes: - In emitFnAttrCompatCheck, change FuncName's type to std::string to fix a use-after-free bug. - Remove an unnecessary install-local target in lib/IR/Makefile. Original commit message for r252949: Provide a way to specify inliner's attribute compatibility and merging rules using table-gen. NFC. This commit adds new classes CompatRule and MergeRule to Attributes.td, which are used to generate code to check attribute compatibility and merge attributes of the caller and callee. rdar://problem/19836465 llvm-svn: 256304
2015-12-23 07:57:37 +08:00
[safestack] Add canary to unsafe stack frames Add StackProtector to SafeStack. This adds limited protection against data corruption in the caller frame. Current implementation treats all stack protector levels as -fstack-protector-all. llvm-svn: 266004
2016-04-12 06:27:48 +08:00
if (Callee.hasFnAttribute(Attribute::StackProtectReq)) {
Rename AttributeSet to AttributeList Summary: This class is a list of AttributeSetNodes corresponding the function prototype of a call or function declaration. This class used to be called ParamAttrListPtr, then AttrListPtr, then AttributeSet. It is typically accessed by parameter and return value index, so "AttributeList" seems like a more intuitive name. Rename AttributeSetImpl to AttributeListImpl to follow suit. It's useful to rename this class so that we can rename AttributeSetNode to AttributeSet later. AttributeSet is the set of attributes that apply to a single function, argument, or return value. Reviewers: sanjoy, javed.absar, chandlerc, pete Reviewed By: pete Subscribers: pete, jholewinski, arsenm, dschuff, mehdi_amini, jfb, nhaehnle, sbc100, void, llvm-commits Differential Revision: https://reviews.llvm.org/D31102 llvm-svn: 298393
2017-03-22 00:57:19 +08:00
Caller.removeAttributes(AttributeList::FunctionIndex, OldSSPAttr);
Provide a way to specify inliner's attribute compatibility and merging. This reapplies r256277 with two changes: - In emitFnAttrCompatCheck, change FuncName's type to std::string to fix a use-after-free bug. - Remove an unnecessary install-local target in lib/IR/Makefile. Original commit message for r252949: Provide a way to specify inliner's attribute compatibility and merging rules using table-gen. NFC. This commit adds new classes CompatRule and MergeRule to Attributes.td, which are used to generate code to check attribute compatibility and merge attributes of the caller and callee. rdar://problem/19836465 llvm-svn: 256304
2015-12-23 07:57:37 +08:00
Caller.addFnAttr(Attribute::StackProtectReq);
} else if (Callee.hasFnAttribute(Attribute::StackProtectStrong) &&
!Caller.hasFnAttribute(Attribute::StackProtectReq)) {
Rename AttributeSet to AttributeList Summary: This class is a list of AttributeSetNodes corresponding the function prototype of a call or function declaration. This class used to be called ParamAttrListPtr, then AttrListPtr, then AttributeSet. It is typically accessed by parameter and return value index, so "AttributeList" seems like a more intuitive name. Rename AttributeSetImpl to AttributeListImpl to follow suit. It's useful to rename this class so that we can rename AttributeSetNode to AttributeSet later. AttributeSet is the set of attributes that apply to a single function, argument, or return value. Reviewers: sanjoy, javed.absar, chandlerc, pete Reviewed By: pete Subscribers: pete, jholewinski, arsenm, dschuff, mehdi_amini, jfb, nhaehnle, sbc100, void, llvm-commits Differential Revision: https://reviews.llvm.org/D31102 llvm-svn: 298393
2017-03-22 00:57:19 +08:00
Caller.removeAttributes(AttributeList::FunctionIndex, OldSSPAttr);
Provide a way to specify inliner's attribute compatibility and merging. This reapplies r256277 with two changes: - In emitFnAttrCompatCheck, change FuncName's type to std::string to fix a use-after-free bug. - Remove an unnecessary install-local target in lib/IR/Makefile. Original commit message for r252949: Provide a way to specify inliner's attribute compatibility and merging rules using table-gen. NFC. This commit adds new classes CompatRule and MergeRule to Attributes.td, which are used to generate code to check attribute compatibility and merge attributes of the caller and callee. rdar://problem/19836465 llvm-svn: 256304
2015-12-23 07:57:37 +08:00
Caller.addFnAttr(Attribute::StackProtectStrong);
} else if (Callee.hasFnAttribute(Attribute::StackProtect) &&
!Caller.hasFnAttribute(Attribute::StackProtectReq) &&
!Caller.hasFnAttribute(Attribute::StackProtectStrong))
Caller.addFnAttr(Attribute::StackProtect);
}
Remove \brief commands from doxygen comments. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46290 llvm-svn: 331272
2018-05-01 23:54:18 +08:00
/// If the inlined function required stack probes, then ensure that
Add a "probe-stack" attribute This attribute is used to ensure the guard page is triggered on stack overflow. Stack frames larger than the guard page size will generate a call to __probestack to touch each page so the guard page won't be skipped. Reviewed By: majnemer Differential Revision: https://reviews.llvm.org/D34386 llvm-svn: 305939
2017-06-22 02:46:50 +08:00
/// the calling function has those too.
static void adjustCallerStackProbes(Function &Caller, const Function &Callee) {
Define behavior of "stack-probe-size" attribute when inlining. Also document the attribute, since "probe-stack" already is. Reviewed By: majnemer Differential Revision: https://reviews.llvm.org/D34528 llvm-svn: 306069
2017-06-23 07:22:36 +08:00
if (!Caller.hasFnAttribute("probe-stack") &&
Callee.hasFnAttribute("probe-stack")) {
Caller.addFnAttr(Callee.getFnAttribute("probe-stack"));
}
}
Remove \brief commands from doxygen comments. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46290 llvm-svn: 331272
2018-05-01 23:54:18 +08:00
/// If the inlined function defines the size of guard region
Define behavior of "stack-probe-size" attribute when inlining. Also document the attribute, since "probe-stack" already is. Reviewed By: majnemer Differential Revision: https://reviews.llvm.org/D34528 llvm-svn: 306069
2017-06-23 07:22:36 +08:00
/// on the stack, then ensure that the calling function defines a guard region
/// that is no larger.
static void
adjustCallerStackProbeSize(Function &Caller, const Function &Callee) {
[Attributes] Merge calls to getFnAttribute/hasFnAttribute using Attribute::isValid. NFC Rather than calling hasFnAttribute and then calling getFnAttribute if the attribute exists, its better to just call getFnAttribute and then check if we got a valid attribute back.
2020-08-29 14:15:34 +08:00
Attribute CalleeAttr = Callee.getFnAttribute("stack-probe-size");
if (CalleeAttr.isValid()) {
Attribute CallerAttr = Caller.getFnAttribute("stack-probe-size");
if (CallerAttr.isValid()) {
uint64_t CallerStackProbeSize, CalleeStackProbeSize;
CallerAttr.getValueAsString().getAsInteger(0, CallerStackProbeSize);
CalleeAttr.getValueAsString().getAsInteger(0, CalleeStackProbeSize);
Define behavior of "stack-probe-size" attribute when inlining. Also document the attribute, since "probe-stack" already is. Reviewed By: majnemer Differential Revision: https://reviews.llvm.org/D34528 llvm-svn: 306069
2017-06-23 07:22:36 +08:00
if (CallerStackProbeSize > CalleeStackProbeSize) {
[Attributes] Merge calls to getFnAttribute/hasFnAttribute using Attribute::isValid. NFC Rather than calling hasFnAttribute and then calling getFnAttribute if the attribute exists, its better to just call getFnAttribute and then check if we got a valid attribute back.
2020-08-29 14:15:34 +08:00
Caller.addFnAttr(CalleeAttr);
Define behavior of "stack-probe-size" attribute when inlining. Also document the attribute, since "probe-stack" already is. Reviewed By: majnemer Differential Revision: https://reviews.llvm.org/D34528 llvm-svn: 306069
2017-06-23 07:22:36 +08:00
}
} else {
[Attributes] Merge calls to getFnAttribute/hasFnAttribute using Attribute::isValid. NFC Rather than calling hasFnAttribute and then calling getFnAttribute if the attribute exists, its better to just call getFnAttribute and then check if we got a valid attribute back.
2020-08-29 14:15:34 +08:00
Caller.addFnAttr(CalleeAttr);
Define behavior of "stack-probe-size" attribute when inlining. Also document the attribute, since "probe-stack" already is. Reviewed By: majnemer Differential Revision: https://reviews.llvm.org/D34528 llvm-svn: 306069
2017-06-23 07:22:36 +08:00
}
}
Add a "probe-stack" attribute This attribute is used to ensure the guard page is triggered on stack overflow. Stack frames larger than the guard page size will generate a call to __probestack to touch each page so the guard page won't be skipped. Reviewed By: majnemer Differential Revision: https://reviews.llvm.org/D34386 llvm-svn: 305939
2017-06-22 02:46:50 +08:00
}
[Inliner] Teach inliner to merge 'min-legal-vector-width' function attribute When we inline a function with a min-legal-vector-width attribute we need to make sure the caller also ends up with at least that vector width. This patch is necessary to make always_inline functions like intrinsics propagate their min-legal-vector-width. Though nothing uses min-legal-vector-width yet. A future patch will add heuristics to preventing inlining with different vector width mismatches. But that code would need to be in inline cost analysis which is separate from the code added here. Differential Revision: https://reviews.llvm.org/D49162 llvm-svn: 337844
2018-07-25 02:49:00 +08:00
/// If the inlined function defines a min legal vector width, then ensure
[Inliner] Modify the merging of min-legal-vector-width attribute to better handle when the caller or callee don't have the attribute. Lack of an attribute means that the function hasn't been checked for what vector width it requires. So if the caller or the callee doesn't have the attribute we should make sure the combined function after inlining does not have the attribute. If the caller already doesn't have the attribute we can just avoid adding it. Otherwise if the callee doesn't have the attribute just remove the caller's attribute. llvm-svn: 347841
2018-11-29 15:27:38 +08:00
/// the calling function has the same or larger min legal vector width. If the
/// caller has the attribute, but the callee doesn't, we need to remove the
/// attribute from the caller since we can't make any guarantees about the
/// caller's requirements.
/// This function is called after the inlining decision has been made so we have
/// to merge the attribute this way. Heuristics that would use
[Inliner] Teach inliner to merge 'min-legal-vector-width' function attribute When we inline a function with a min-legal-vector-width attribute we need to make sure the caller also ends up with at least that vector width. This patch is necessary to make always_inline functions like intrinsics propagate their min-legal-vector-width. Though nothing uses min-legal-vector-width yet. A future patch will add heuristics to preventing inlining with different vector width mismatches. But that code would need to be in inline cost analysis which is separate from the code added here. Differential Revision: https://reviews.llvm.org/D49162 llvm-svn: 337844
2018-07-25 02:49:00 +08:00
/// min-legal-vector-width to determine inline compatibility would need to be
/// handled as part of inline cost analysis.
static void
adjustMinLegalVectorWidth(Function &Caller, const Function &Callee) {
[Attributes] Merge calls to getFnAttribute/hasFnAttribute using Attribute::isValid. NFC Rather than calling hasFnAttribute and then calling getFnAttribute if the attribute exists, its better to just call getFnAttribute and then check if we got a valid attribute back.
2020-08-29 14:15:34 +08:00
Attribute CallerAttr = Caller.getFnAttribute("min-legal-vector-width");
if (CallerAttr.isValid()) {
Attribute CalleeAttr = Callee.getFnAttribute("min-legal-vector-width");
if (CalleeAttr.isValid()) {
uint64_t CallerVectorWidth, CalleeVectorWidth;
CallerAttr.getValueAsString().getAsInteger(0, CallerVectorWidth);
CalleeAttr.getValueAsString().getAsInteger(0, CalleeVectorWidth);
[Inliner] Modify the merging of min-legal-vector-width attribute to better handle when the caller or callee don't have the attribute. Lack of an attribute means that the function hasn't been checked for what vector width it requires. So if the caller or the callee doesn't have the attribute we should make sure the combined function after inlining does not have the attribute. If the caller already doesn't have the attribute we can just avoid adding it. Otherwise if the callee doesn't have the attribute just remove the caller's attribute. llvm-svn: 347841
2018-11-29 15:27:38 +08:00
if (CallerVectorWidth < CalleeVectorWidth)
[Attributes] Merge calls to getFnAttribute/hasFnAttribute using Attribute::isValid. NFC Rather than calling hasFnAttribute and then calling getFnAttribute if the attribute exists, its better to just call getFnAttribute and then check if we got a valid attribute back.
2020-08-29 14:15:34 +08:00
Caller.addFnAttr(CalleeAttr);
[Inliner] Teach inliner to merge 'min-legal-vector-width' function attribute When we inline a function with a min-legal-vector-width attribute we need to make sure the caller also ends up with at least that vector width. This patch is necessary to make always_inline functions like intrinsics propagate their min-legal-vector-width. Though nothing uses min-legal-vector-width yet. A future patch will add heuristics to preventing inlining with different vector width mismatches. But that code would need to be in inline cost analysis which is separate from the code added here. Differential Revision: https://reviews.llvm.org/D49162 llvm-svn: 337844
2018-07-25 02:49:00 +08:00
} else {
[Inliner] Modify the merging of min-legal-vector-width attribute to better handle when the caller or callee don't have the attribute. Lack of an attribute means that the function hasn't been checked for what vector width it requires. So if the caller or the callee doesn't have the attribute we should make sure the combined function after inlining does not have the attribute. If the caller already doesn't have the attribute we can just avoid adding it. Otherwise if the callee doesn't have the attribute just remove the caller's attribute. llvm-svn: 347841
2018-11-29 15:27:38 +08:00
// If the callee doesn't have the attribute then we don't know anything
// and must drop the attribute from the caller.
Caller.removeFnAttr("min-legal-vector-width");
[Inliner] Teach inliner to merge 'min-legal-vector-width' function attribute When we inline a function with a min-legal-vector-width attribute we need to make sure the caller also ends up with at least that vector width. This patch is necessary to make always_inline functions like intrinsics propagate their min-legal-vector-width. Though nothing uses min-legal-vector-width yet. A future patch will add heuristics to preventing inlining with different vector width mismatches. But that code would need to be in inline cost analysis which is separate from the code added here. Differential Revision: https://reviews.llvm.org/D49162 llvm-svn: 337844
2018-07-25 02:49:00 +08:00
}
}
}
[IR] Convert null-pointer-is-valid into an enum attribute The "null-pointer-is-valid" attribute needs to be checked by many pointer-related combines. To make the check more efficient, convert it from a string into an enum attribute. In the future, this attribute may be replaced with data layout properties. Differential Revision: https://reviews.llvm.org/D78862
2020-04-25 18:57:07 +08:00
/// If the inlined function has null_pointer_is_valid attribute,
[Inline] Copy "null-pointer-is-valid" attribute in caller. Summary: Normally, inling does not happen if caller does not have "null-pointer-is-valid"="true" attibute but callee has it. However, alwaysinline may force callee to be inlined. In this case, if the caller has the "null-pointer-is-valid"="true" attribute, copy the attribute to caller. Reviewers: efriedma, a.elovikov, lebedev.ri, jyknight Reviewed By: efriedma Subscribers: eraman, llvm-commits Differential Revision: https://reviews.llvm.org/D50000 llvm-svn: 338292
2018-07-31 03:33:53 +08:00
/// set this attribute in the caller post inlining.
static void
adjustNullPointerValidAttr(Function &Caller, const Function &Callee) {
if (Callee.nullPointerIsDefined() && !Caller.nullPointerIsDefined()) {
[IR] Convert null-pointer-is-valid into an enum attribute The "null-pointer-is-valid" attribute needs to be checked by many pointer-related combines. To make the check more efficient, convert it from a string into an enum attribute. In the future, this attribute may be replaced with data layout properties. Differential Revision: https://reviews.llvm.org/D78862
2020-04-25 18:57:07 +08:00
Caller.addFnAttr(Attribute::NullPointerIsValid);
[Inline] Copy "null-pointer-is-valid" attribute in caller. Summary: Normally, inling does not happen if caller does not have "null-pointer-is-valid"="true" attibute but callee has it. However, alwaysinline may force callee to be inlined. In this case, if the caller has the "null-pointer-is-valid"="true" attribute, copy the attribute to caller. Reviewers: efriedma, a.elovikov, lebedev.ri, jyknight Reviewed By: efriedma Subscribers: eraman, llvm-commits Differential Revision: https://reviews.llvm.org/D50000 llvm-svn: 338292
2018-07-31 03:33:53 +08:00
}
}
[NFC] Refactor TableGen for attributes Summary: this patch makes tablegen generate llvm attributes in a more generic and simpler (at least to me). changes: make tablegen generate ... ATTRIBUTE_ENUM(Alignment,align) ATTRIBUTE_ENUM(AllocSize,allocsize) ... which can be used to generate most of what was previously used and more. Tablegen was also generating attributes from 2 identical files leading to identical output. so I removed one of them and made user use the other. Reviewers: jdoerfert, thakis, aaron.ballman Reviewed By: aaron.ballman Subscribers: mgorny, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D72455
2020-02-02 21:46:50 +08:00
struct EnumAttr {
static bool isSet(const Function &Fn,
Attribute::AttrKind Kind) {
return Fn.hasFnAttribute(Kind);
}
static void set(Function &Fn,
Attribute::AttrKind Kind, bool Val) {
if (Val)
Fn.addFnAttr(Kind);
else
Fn.removeFnAttr(Kind);
}
};
struct StrBoolAttr {
static bool isSet(const Function &Fn,
StringRef Kind) {
auto A = Fn.getFnAttribute(Kind);
return A.getValueAsString().equals("true");
}
static void set(Function &Fn,
StringRef Kind, bool Val) {
Fn.addFnAttr(Kind, Val ? "true" : "false");
}
};
#define GET_ATTR_NAMES
#define ATTRIBUTE_ENUM(ENUM_NAME, DISPLAY_NAME) \
struct ENUM_NAME##Attr : EnumAttr { \
static enum Attribute::AttrKind getKind() { \
return llvm::Attribute::ENUM_NAME; \
} \
};
#define ATTRIBUTE_STRBOOL(ENUM_NAME, DISPLAY_NAME) \
struct ENUM_NAME##Attr : StrBoolAttr { \
static StringRef getKind() { return #DISPLAY_NAME; } \
};
#include "llvm/IR/Attributes.inc"
Provide a way to specify inliner's attribute compatibility and merging. This reapplies r256277 with two changes: - In emitFnAttrCompatCheck, change FuncName's type to std::string to fix a use-after-free bug. - Remove an unnecessary install-local target in lib/IR/Makefile. Original commit message for r252949: Provide a way to specify inliner's attribute compatibility and merging rules using table-gen. NFC. This commit adds new classes CompatRule and MergeRule to Attributes.td, which are used to generate code to check attribute compatibility and merge attributes of the caller and callee. rdar://problem/19836465 llvm-svn: 256304
2015-12-23 07:57:37 +08:00
#define GET_ATTR_COMPAT_FUNC
[NFC] Refactor TableGen for attributes Summary: this patch makes tablegen generate llvm attributes in a more generic and simpler (at least to me). changes: make tablegen generate ... ATTRIBUTE_ENUM(Alignment,align) ATTRIBUTE_ENUM(AllocSize,allocsize) ... which can be used to generate most of what was previously used and more. Tablegen was also generating attributes from 2 identical files leading to identical output. so I removed one of them and made user use the other. Reviewers: jdoerfert, thakis, aaron.ballman Reviewed By: aaron.ballman Subscribers: mgorny, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D72455
2020-02-02 21:46:50 +08:00
#include "llvm/IR/Attributes.inc"
Provide a way to specify inliner's attribute compatibility and merging. This reapplies r256277 with two changes: - In emitFnAttrCompatCheck, change FuncName's type to std::string to fix a use-after-free bug. - Remove an unnecessary install-local target in lib/IR/Makefile. Original commit message for r252949: Provide a way to specify inliner's attribute compatibility and merging rules using table-gen. NFC. This commit adds new classes CompatRule and MergeRule to Attributes.td, which are used to generate code to check attribute compatibility and merge attributes of the caller and callee. rdar://problem/19836465 llvm-svn: 256304
2015-12-23 07:57:37 +08:00
bool AttributeFuncs::areInlineCompatible(const Function &Caller,
const Function &Callee) {
return hasCompatibleFnAttrs(Caller, Callee);
}
[IROutliner] Adding consistent function attribute merging When combining extracted functions, they may have different function attributes. We want to make sure that we do not make any assumptions, or lose any information. This attempts to make sure that we consolidate function attributes to their most general case. Tests: llvm/test/Transforms/IROutliner/outlining-compatible-and-attribute-transfer.ll llvm/test/Transforms/IROutliner/outlining-compatible-or-attribute-transfer.ll Reviewers: jdoefert, paquette Differential Revision: https://reviews.llvm.org/D87301
2020-08-24 16:24:59 +08:00
bool AttributeFuncs::areOutlineCompatible(const Function &A,
const Function &B) {
return hasCompatibleFnAttrs(A, B);
}
Provide a way to specify inliner's attribute compatibility and merging. This reapplies r256277 with two changes: - In emitFnAttrCompatCheck, change FuncName's type to std::string to fix a use-after-free bug. - Remove an unnecessary install-local target in lib/IR/Makefile. Original commit message for r252949: Provide a way to specify inliner's attribute compatibility and merging rules using table-gen. NFC. This commit adds new classes CompatRule and MergeRule to Attributes.td, which are used to generate code to check attribute compatibility and merge attributes of the caller and callee. rdar://problem/19836465 llvm-svn: 256304
2015-12-23 07:57:37 +08:00
void AttributeFuncs::mergeAttributesForInlining(Function &Caller,
const Function &Callee) {
mergeFnAttrs(Caller, Callee);
}
[IROutliner] Adding consistent function attribute merging When combining extracted functions, they may have different function attributes. We want to make sure that we do not make any assumptions, or lose any information. This attempts to make sure that we consolidate function attributes to their most general case. Tests: llvm/test/Transforms/IROutliner/outlining-compatible-and-attribute-transfer.ll llvm/test/Transforms/IROutliner/outlining-compatible-or-attribute-transfer.ll Reviewers: jdoefert, paquette Differential Revision: https://reviews.llvm.org/D87301
2020-08-24 16:24:59 +08:00
void AttributeFuncs::mergeAttributesForOutlining(Function &Base,
const Function &ToMerge) {
// We merge functions so that they meet the most general case.
// For example, if the NoNansFPMathAttr is set in one function, but not in
// the other, in the merged function we can say that the NoNansFPMathAttr
// is not set.
// However if we have the SpeculativeLoadHardeningAttr set true in one
// function, but not the other, we make sure that the function retains
// that aspect in the merged function.
mergeFnAttrs(Base, ToMerge);
}