mirrors/llvm-project
0
0
Fork 0
mirror of https://github.com/llvm/llvm-project.git synced 2025-04-28 21:36:04 +00:00
Code Issues Projects 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.

2078 lines
68 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 00:00:09 +00: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-02 23:42:30 +00: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 08:50:56 +00: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-02 23:42:30 +00: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-28 21:55:20 +00: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 15:54:18 +00: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-21 16:57:19 +00: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-02 23:42:30 +00: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 11:49:48 +00: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 01:36:59 +00: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-26 21:07:29 +00: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 00:00:09 +00: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-12 16:15:53 +00: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 11:49:48 +00: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-03 16:50:05 +00: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 00:00:09 +00: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-02-29 10:23:54 -08:00
#include "llvm/ADT/StringSwitch.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 14:59:11 +00: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 00:00:09 +00: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 11:36:10 +00: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 00:00:09 +00:00
#include "llvm/Support/Compiler.h"
#include "llvm/Support/ErrorHandling.h"
Kill off more cerr/cout uses and prune includes a bit. llvm-svn: 79852
2009-08-23 11:37:21 +00: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 00:06:56 +00: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 00:00:09 +00:00
#include <cassert>
[IR] Fix some Clang-tidy modernize-use-using warnings; other minor fixes (NFC). llvm-svn: 303119
2017-05-15 21:57:41 +00:00
#include <cstddef>
[IR] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC). llvm-svn: 295383
2017-02-17 00:00:09 +00: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-02 23:42:30 +00: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-12 17:45:29 +00:00
//===----------------------------------------------------------------------===//
S'more small non-functional changes in comments and #includes. llvm-svn: 173738
2013-01-29 00:48:16 +00: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-12 17:45:29 +00: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-14 19:52:09 +00: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 01:05:35 +00: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 01:05:08 +00: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 01:05:35 +00:00
static uint64_t packAllocSizeArgs(unsigned ElemSizeArg,
const Optional<unsigned> &NumElemsArg) {
Don't use Optional::hasValue (NFC)
2022-06-20 11:49:10 -07:00
assert((!NumElemsArg || *NumElemsArg != AllocSizeNumElemsNotPresent) &&
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 01:05:35 +00:00
"Attempting to pack a reserved value");
return uint64_t(ElemSizeArg) << 32 |
[llvm] Use value_or instead of getValueOr (NFC)
2022-06-18 23:07:11 -07:00
NumElemsArg.value_or(AllocSizeNumElemsNotPresent);
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 01:05:35 +00:00
}
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);
}
[IR] Split vscale_range interface Interface is split from: std::pair<unsigned, unsigned> getVScaleRangeArgs() into separate functions for min/max: unsigned getVScaleRangeMin(); Optional<unsigned> getVScaleRangeMax(); Reviewed By: sdesmalen, paulwalker-arm Differential Revision: https://reviews.llvm.org/D114075
2021-12-07 09:53:16 +00:00
static uint64_t packVScaleRangeArgs(unsigned MinValue,
Optional<unsigned> MaxValue) {
[llvm] Use value_or instead of getValueOr (NFC)
2022-06-18 23:07:11 -07:00
return uint64_t(MinValue) << 32 | MaxValue.value_or(0);
[IR] Add vscale_range IR function attribute This attribute represents the minimum and maximum values vscale can take. For now this attribute is not hooked up to anything during codegen, this will be added in the future when such codegen is considered stable. Additionally hook up the -msve-vector-bits=<x> clang option to emit this attribute. Differential Revision: https://reviews.llvm.org/D98030
2021-03-03 13:53:30 +00:00
}
[IR] Split vscale_range interface Interface is split from: std::pair<unsigned, unsigned> getVScaleRangeArgs() into separate functions for min/max: unsigned getVScaleRangeMin(); Optional<unsigned> getVScaleRangeMax(); Reviewed By: sdesmalen, paulwalker-arm Differential Revision: https://reviews.llvm.org/D114075
2021-12-07 09:53:16 +00:00
static std::pair<unsigned, Optional<unsigned>>
unpackVScaleRangeArgs(uint64_t Value) {
[IR] Add vscale_range IR function attribute This attribute represents the minimum and maximum values vscale can take. For now this attribute is not hooked up to anything during codegen, this will be added in the future when such codegen is considered stable. Additionally hook up the -msve-vector-bits=<x> clang option to emit this attribute. Differential Revision: https://reviews.llvm.org/D98030
2021-03-03 13:53:30 +00:00
unsigned MaxValue = Value & std::numeric_limits<unsigned>::max();
unsigned MinValue = Value >> 32;
[IR] Split vscale_range interface Interface is split from: std::pair<unsigned, unsigned> getVScaleRangeArgs() into separate functions for min/max: unsigned getVScaleRangeMin(); Optional<unsigned> getVScaleRangeMax(); Reviewed By: sdesmalen, paulwalker-arm Differential Revision: https://reviews.llvm.org/D114075
2021-12-07 09:53:16 +00:00
return std::make_pair(MinValue,
MaxValue > 0 ? MaxValue : Optional<unsigned>());
[IR] Add vscale_range IR function attribute This attribute represents the minimum and maximum values vscale can take. For now this attribute is not hooked up to anything during codegen, this will be added in the future when such codegen is considered stable. Additionally hook up the -msve-vector-bits=<x> clang option to emit this attribute. Differential Revision: https://reviews.llvm.org/D98030
2021-03-03 13:53:30 +00: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-05 22:37:24 +00:00
Attribute Attribute::get(LLVMContext &Context, Attribute::AttrKind Kind,
uint64_t Val) {
[Attributes] Assert correct attribute constructor is used (NFCI) Assert that enum/int/type attributes go through the constructor they are supposed to use. To make sure this can't happen via invalid bitcode, explicitly verify that the attribute kind if correct there.
2021-07-12 20:54:58 +02:00
if (Val)
assert(Attribute::isIntAttrKind(Kind) && "Not an int attribute");
else
assert(Attribute::isEnumAttrKind(Kind) && "Not an enum attribute");
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-08 21:47:17 +00: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-05 22:37:24 +00:00
ID.AddInteger(Kind);
Revert accidentally committed r217107 "Don't treat 0 as a special value for int attributes." llvm-svn: 217110
2014-09-03 23:38:05 +00: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-08 21:47:17 +00:00
void *InsertPoint;
s/AttributesImpl/AttributeImpl/g This is going to apply to Attribute, not Attributes. llvm-svn: 170631
2012-12-20 01:36:59 +00: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-08 21:47:17 +00: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-03 23:38:05 +00:00
if (!Val)
[IR] Make Attributes and AttributeLists trivially destructible and BumpPtrAllocate them
2020-05-01 14:12:17 +02: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-03 23:38:05 +00:00
else
[IR] Make Attributes and AttributeLists trivially destructible and BumpPtrAllocate them
2020-05-01 14:12:17 +02: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-08 21:47:17 +00:00
pImpl->AttrsSet.InsertNode(PA, InsertPoint);
}
Add target-dependent versions of addAttribute/removeAttribute to AttrBuilder. llvm-svn: 174356
2013-02-05 08:09:32 +00: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 07:18:57 +00: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-08 21:47:17 +00: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-05 22:37:24 +00: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 14:12:17 +02: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-05 22:37:24 +00: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-01-31 23:16:25 +00: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-30 18:48:23 +00:00
Attribute Attribute::get(LLVMContext &Context, Attribute::AttrKind Kind,
Type *Ty) {
[Attributes] Make type attribute handling more generic (NFCI) Followup to D105658 to make AttrBuilder automatically work with new type attributes. TableGen is tweaked to emit First/LastTypeAttr markers, based on which we can handle type attributes programmatically. Differential Revision: https://reviews.llvm.org/D105763
2021-07-10 18:36:00 +02:00
assert(Attribute::isTypeAttrKind(Kind) && "Not a type attribute");
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-30 18:48:23 +00:00
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 14:12:17 +02: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-30 18:48:23 +00: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 12:56:24 +00: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-23 22:50:06 +03: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 12:56:24 +00: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-27 22:43:04 +00: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 12:56:24 +00: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-27 22:43:04 +00: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 15:51:28 +00: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-16 20:29:50 +00: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-30 18:48:23 +00: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 09:33:55 -04: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-05 16:58:47 -04: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-14 14:16:53 -08:00
Attribute Attribute::getWithPreallocatedType(LLVMContext &Context, Type *Ty) {
return get(Context, Preallocated, Ty);
}
Reapply "OpaquePtr: Turn inalloca into a type attribute" This reverts commit 07e46367baeca96d84b03fa215b41775f69d5989.
2021-03-29 08:42:23 -04:00
Attribute Attribute::getWithInAllocaType(LLVMContext &Context, Type *Ty) {
return get(Context, InAlloca, Ty);
}
Extend the `uwtable` attribute with unwind table kind We have the `clang -cc1` command-line option `-funwind-tables=1|2` and the codegen option `VALUE_CODEGENOPT(UnwindTables, 2, 0) ///< Unwind tables (1) or asynchronous unwind tables (2)`. However, this is encoded in LLVM IR by the presence or the absence of the `uwtable` attribute, i.e. we lose the information whether to generate want just some unwind tables or asynchronous unwind tables. Asynchronous unwind tables take more space in the runtime image, I'd estimate something like 80-90% more, as the difference is adding roughly the same number of CFI directives as for prologues, only a bit simpler (e.g. `.cfi_offset reg, off` vs. `.cfi_restore reg`). Or even more, if you consider tail duplication of epilogue blocks. Asynchronous unwind tables could also restrict code generation to having only a finite number of frame pointer adjustments (an example of *not* having a finite number of `SP` adjustments is on AArch64 when untagging the stack (MTE) in some cases the compiler can modify `SP` in a loop). Having the CFI precise up to an instruction generally also means one cannot bundle together CFI instructions once the prologue is done, they need to be interspersed with ordinary instructions, which means extra `DW_CFA_advance_loc` commands, further increasing the unwind tables size. That is to say, async unwind tables impose a non-negligible overhead, yet for the most common use cases (like C++ exceptions), they are not even needed. This patch extends the `uwtable` attribute with an optional value: - `uwtable` (default to `async`) - `uwtable(sync)`, synchronous unwind tables - `uwtable(async)`, asynchronous (instruction precise) unwind tables Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D114543
2022-02-14 13:41:34 +00:00
Attribute Attribute::getWithUWTableKind(LLVMContext &Context,
UWTableKind Kind) {
return get(Context, UWTable, uint64_t(Kind));
}
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 01:05:35 +00: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));
}
[IR] Add vscale_range IR function attribute This attribute represents the minimum and maximum values vscale can take. For now this attribute is not hooked up to anything during codegen, this will be added in the future when such codegen is considered stable. Additionally hook up the -msve-vector-bits=<x> clang option to emit this attribute. Differential Revision: https://reviews.llvm.org/D98030
2021-03-03 13:53:30 +00:00
Attribute Attribute::getWithVScaleRangeArgs(LLVMContext &Context,
unsigned MinValue,
unsigned MaxValue) {
return get(Context, VScaleRange, packVScaleRangeArgs(MinValue, MaxValue));
}
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 14:46:59 +01: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");
}
}
[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-11 23:21:44 +01: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 00:48:16 +00: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-05 22:37:24 +00: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 06:44:41 +00: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 06:51:55 +00: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-29 20:45:34 +00: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-05 22:37:24 +00: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-30 18:48:23 +00: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-05 22:37:24 +00: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 00:34:29 +00: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-30 18:48:23 +00: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-05 22:37:24 +00:00
"Invalid attribute type to get the kind as an enum!");
Minor cleanup of Attribute code. NFC. llvm-svn: 255751
2015-12-16 05:21:02 +00: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-05 22:37:24 +00: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 00:34:29 +00: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 06:51:55 +00:00
assert(isIntAttribute() &&
"Expected the attribute to be an integer attribute!");
Minor cleanup of Attribute code. NFC. llvm-svn: 255751
2015-12-16 05:21:02 +00: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-05 22:37:24 +00:00
}
Normalize interaction with boolean attributes Such attributes can either be unset, or set to "true" or "false" (as string). throughout the codebase, this led to inelegant checks ranging from if (Fn->getFnAttribute("no-jump-tables").getValueAsString() == "true") to if (Fn->hasAttribute("no-jump-tables") && Fn->getFnAttribute("no-jump-tables").getValueAsString() == "true") Introduce a getValueAsBool that normalize the check, with the following behavior: no attributes or attribute set to "false" => return false attribute set to "true" => return true Differential Revision: https://reviews.llvm.org/D99299
2021-03-24 16:45:04 -04:00
bool Attribute::getValueAsBool() const {
if (!pImpl) return false;
assert(isStringAttribute() &&
"Expected the attribute to be a string attribute!");
return pImpl->getValueAsBool();
}
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-05 22:37:24 +00:00
StringRef Attribute::getKindAsString() const {
[IR] Fix some Clang-tidy modernize-use-auto warnings; other minor fixes (NFC). llvm-svn: 328850
2018-03-30 00:47:31 +00: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-05 22:37:24 +00: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 05:21:02 +00: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-05 22:37:24 +00:00
}
StringRef Attribute::getValueAsString() const {
[IR] Fix some Clang-tidy modernize-use-auto warnings; other minor fixes (NFC). llvm-svn: 328850
2018-03-30 00:47:31 +00: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-05 22:37:24 +00: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 05:21:02 +00: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-05 22:37:24 +00: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-30 18:48:23 +00: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-05 23:48:36 +00: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-29 20:45:34 +00: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 09:51:06 +00: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 01:04:27 +00: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 09:51:06 +00: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 06:44:41 +00: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 09:51:06 +00: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 01:04:27 +00: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 09:51:06 +00: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 06:44:41 +00: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 15:51:28 +00: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-16 20:29:50 +00: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 01:05:35 +00: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());
}
[IR] Split vscale_range interface Interface is split from: std::pair<unsigned, unsigned> getVScaleRangeArgs() into separate functions for min/max: unsigned getVScaleRangeMin(); Optional<unsigned> getVScaleRangeMax(); Reviewed By: sdesmalen, paulwalker-arm Differential Revision: https://reviews.llvm.org/D114075
2021-12-07 09:53:16 +00:00
unsigned Attribute::getVScaleRangeMin() const {
[IR] Add vscale_range IR function attribute This attribute represents the minimum and maximum values vscale can take. For now this attribute is not hooked up to anything during codegen, this will be added in the future when such codegen is considered stable. Additionally hook up the -msve-vector-bits=<x> clang option to emit this attribute. Differential Revision: https://reviews.llvm.org/D98030
2021-03-03 13:53:30 +00:00
assert(hasAttribute(Attribute::VScaleRange) &&
"Trying to get vscale args from non-vscale attribute");
[IR] Split vscale_range interface Interface is split from: std::pair<unsigned, unsigned> getVScaleRangeArgs() into separate functions for min/max: unsigned getVScaleRangeMin(); Optional<unsigned> getVScaleRangeMax(); Reviewed By: sdesmalen, paulwalker-arm Differential Revision: https://reviews.llvm.org/D114075
2021-12-07 09:53:16 +00:00
return unpackVScaleRangeArgs(pImpl->getValueAsInt()).first;
}
Optional<unsigned> Attribute::getVScaleRangeMax() const {
assert(hasAttribute(Attribute::VScaleRange) &&
"Trying to get vscale args from non-vscale attribute");
return unpackVScaleRangeArgs(pImpl->getValueAsInt()).second;
[IR] Add vscale_range IR function attribute This attribute represents the minimum and maximum values vscale can take. For now this attribute is not hooked up to anything during codegen, this will be added in the future when such codegen is considered stable. Additionally hook up the -msve-vector-bits=<x> clang option to emit this attribute. Differential Revision: https://reviews.llvm.org/D98030
2021-03-03 13:53:30 +00:00
}
Extend the `uwtable` attribute with unwind table kind We have the `clang -cc1` command-line option `-funwind-tables=1|2` and the codegen option `VALUE_CODEGENOPT(UnwindTables, 2, 0) ///< Unwind tables (1) or asynchronous unwind tables (2)`. However, this is encoded in LLVM IR by the presence or the absence of the `uwtable` attribute, i.e. we lose the information whether to generate want just some unwind tables or asynchronous unwind tables. Asynchronous unwind tables take more space in the runtime image, I'd estimate something like 80-90% more, as the difference is adding roughly the same number of CFI directives as for prologues, only a bit simpler (e.g. `.cfi_offset reg, off` vs. `.cfi_restore reg`). Or even more, if you consider tail duplication of epilogue blocks. Asynchronous unwind tables could also restrict code generation to having only a finite number of frame pointer adjustments (an example of *not* having a finite number of `SP` adjustments is on AArch64 when untagging the stack (MTE) in some cases the compiler can modify `SP` in a loop). Having the CFI precise up to an instruction generally also means one cannot bundle together CFI instructions once the prologue is done, they need to be interspersed with ordinary instructions, which means extra `DW_CFA_advance_loc` commands, further increasing the unwind tables size. That is to say, async unwind tables impose a non-negligible overhead, yet for the most common use cases (like C++ exceptions), they are not even needed. This patch extends the `uwtable` attribute with an optional value: - `uwtable` (default to `async`) - `uwtable(sync)`, synchronous unwind tables - `uwtable(async)`, asynchronous (instruction precise) unwind tables Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D114543
2022-02-14 13:41:34 +00:00
UWTableKind Attribute::getUWTableKind() const {
assert(hasAttribute(Attribute::UWTable) &&
"Trying to get unwind table kind from non-uwtable attribute");
return UWTableKind(pImpl->getValueAsInt());
}
attributes: introduce allockind attr for describing allocator fn behavior I chose to encode the allockind information in a string constant because otherwise we would get a bit of an explosion of keywords to deal with the possible permutations of allocation function types. I'm not sure that CodeGen.h is the correct place for this enum, but it seemed to kind of match the UWTableKind enum so I put it in the same place. Constructive suggestions on a better location most certainly encouraged. Differential Revision: https://reviews.llvm.org/D123088
2022-03-29 11:14:07 -04:00
AllocFnKind Attribute::getAllocKind() const {
assert(hasAttribute(Attribute::AllocKind) &&
"Trying to get allockind value from non-allockind attribute");
return AllocFnKind(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 08:43:33 +00: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 00:47:31 +00: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-01-31 20:59:05 +00:00
[IR] Simplify Attribute::getAsString() (NFC) Avoid enumerating all attributes here and instead use getNameFromAttrKind(), which is based on the tablegen data. This only leaves us with custom handling for int attributes, which don't have uniform printing.
2021-07-07 22:41:12 +02:00
if (isEnumAttribute())
return getNameFromAttrKind(getKindAsEnum()).str();
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-01-31 20:59:05 +00:00
Reapply "OpaquePtr: Turn inalloca into a type attribute" This reverts commit 07e46367baeca96d84b03fa215b41775f69d5989.
2021-03-29 08:42:23 -04:00
if (isTypeAttribute()) {
[IR] Simplify Attribute::getAsString() (NFC) Avoid enumerating all attributes here and instead use getNameFromAttrKind(), which is based on the tablegen data. This only leaves us with custom handling for int attributes, which don't have uniform printing.
2021-07-07 22:41:12 +02:00
std::string Result = getNameFromAttrKind(getKindAsEnum()).str();
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-14 14:16:53 -08:00
Result += '(';
[IR] Simplify Attribute::getAsString() (NFC) Avoid enumerating all attributes here and instead use getNameFromAttrKind(), which is based on the tablegen data. This only leaves us with custom handling for int attributes, which don't have uniform printing.
2021-07-07 22:41:12 +02:00
raw_string_ostream OS(Result);
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-14 14:16:53 -08:00
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-01-31 20:59:05 +00:00
// FIXME: These should be output like this:
//
// align=4
// alignstack=8
//
Save some `std::string` allocations/deallocations when formatting attributes (NFC) Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D118451
2022-01-31 10:48:14 +00:00
if (hasAttribute(Attribute::Alignment))
return (InAttrGrp ? "align=" + Twine(getValueAsInt())
: "align " + Twine(getValueAsInt()))
.str();
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 08:43:33 +00: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-16 20:29:50 +00:00
auto AttrWithBytesToString = [&](const char *Name) {
Save some `std::string` allocations/deallocations when formatting attributes (NFC) Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D118451
2022-01-31 10:48:14 +00:00
return (InAttrGrp ? Name + ("=" + Twine(getValueAsInt()))
: Name + ("(" + Twine(getValueAsInt())) + ")")
.str();
[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-16 20:29:50 +00: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-01-31 20:59:05 +00: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-16 20:29:50 +00: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 15:51:28 +00: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 01:05:35 +00:00
if (hasAttribute(Attribute::AllocSize)) {
unsigned ElemSize;
Optional<unsigned> NumElems;
std::tie(ElemSize, NumElems) = getAllocSizeArgs();
Save some `std::string` allocations/deallocations when formatting attributes (NFC) Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D118451
2022-01-31 10:48:14 +00:00
return (NumElems
? "allocsize(" + Twine(ElemSize) + "," + Twine(*NumElems) + ")"
: "allocsize(" + Twine(ElemSize) + ")")
.str();
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 01:05:35 +00:00
}
[IR] Add vscale_range IR function attribute This attribute represents the minimum and maximum values vscale can take. For now this attribute is not hooked up to anything during codegen, this will be added in the future when such codegen is considered stable. Additionally hook up the -msve-vector-bits=<x> clang option to emit this attribute. Differential Revision: https://reviews.llvm.org/D98030
2021-03-03 13:53:30 +00:00
if (hasAttribute(Attribute::VScaleRange)) {
[IR] Split vscale_range interface Interface is split from: std::pair<unsigned, unsigned> getVScaleRangeArgs() into separate functions for min/max: unsigned getVScaleRangeMin(); Optional<unsigned> getVScaleRangeMax(); Reviewed By: sdesmalen, paulwalker-arm Differential Revision: https://reviews.llvm.org/D114075
2021-12-07 09:53:16 +00:00
unsigned MinValue = getVScaleRangeMin();
Optional<unsigned> MaxValue = getVScaleRangeMax();
Save some `std::string` allocations/deallocations when formatting attributes (NFC) Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D118451
2022-01-31 10:48:14 +00:00
return ("vscale_range(" + Twine(MinValue) + "," +
[llvm] Use value_or instead of getValueOr (NFC)
2022-06-18 23:07:11 -07:00
Twine(MaxValue.value_or(0)) + ")")
Save some `std::string` allocations/deallocations when formatting attributes (NFC) Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D118451
2022-01-31 10:48:14 +00:00
.str();
[IR] Add vscale_range IR function attribute This attribute represents the minimum and maximum values vscale can take. For now this attribute is not hooked up to anything during codegen, this will be added in the future when such codegen is considered stable. Additionally hook up the -msve-vector-bits=<x> clang option to emit this attribute. Differential Revision: https://reviews.llvm.org/D98030
2021-03-03 13:53:30 +00:00
}
Extend the `uwtable` attribute with unwind table kind We have the `clang -cc1` command-line option `-funwind-tables=1|2` and the codegen option `VALUE_CODEGENOPT(UnwindTables, 2, 0) ///< Unwind tables (1) or asynchronous unwind tables (2)`. However, this is encoded in LLVM IR by the presence or the absence of the `uwtable` attribute, i.e. we lose the information whether to generate want just some unwind tables or asynchronous unwind tables. Asynchronous unwind tables take more space in the runtime image, I'd estimate something like 80-90% more, as the difference is adding roughly the same number of CFI directives as for prologues, only a bit simpler (e.g. `.cfi_offset reg, off` vs. `.cfi_restore reg`). Or even more, if you consider tail duplication of epilogue blocks. Asynchronous unwind tables could also restrict code generation to having only a finite number of frame pointer adjustments (an example of *not* having a finite number of `SP` adjustments is on AArch64 when untagging the stack (MTE) in some cases the compiler can modify `SP` in a loop). Having the CFI precise up to an instruction generally also means one cannot bundle together CFI instructions once the prologue is done, they need to be interspersed with ordinary instructions, which means extra `DW_CFA_advance_loc` commands, further increasing the unwind tables size. That is to say, async unwind tables impose a non-negligible overhead, yet for the most common use cases (like C++ exceptions), they are not even needed. This patch extends the `uwtable` attribute with an optional value: - `uwtable` (default to `async`) - `uwtable(sync)`, synchronous unwind tables - `uwtable(async)`, asynchronous (instruction precise) unwind tables Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D114543
2022-02-14 13:41:34 +00:00
if (hasAttribute(Attribute::UWTable)) {
UWTableKind Kind = getUWTableKind();
if (Kind != UWTableKind::None) {
return Kind == UWTableKind::Default
? "uwtable"
: ("uwtable(" +
Twine(Kind == UWTableKind::Sync ? "sync" : "async") + ")")
.str();
}
}
attributes: introduce allockind attr for describing allocator fn behavior I chose to encode the allockind information in a string constant because otherwise we would get a bit of an explosion of keywords to deal with the possible permutations of allocation function types. I'm not sure that CodeGen.h is the correct place for this enum, but it seemed to kind of match the UWTableKind enum so I put it in the same place. Constructive suggestions on a better location most certainly encouraged. Differential Revision: https://reviews.llvm.org/D123088
2022-03-29 11:14:07 -04:00
if (hasAttribute(Attribute::AllocKind)) {
AllocFnKind Kind = getAllocKind();
SmallVector<StringRef> parts;
if ((Kind & AllocFnKind::Alloc) != AllocFnKind::Unknown)
parts.push_back("alloc");
if ((Kind & AllocFnKind::Realloc) != AllocFnKind::Unknown)
parts.push_back("realloc");
if ((Kind & AllocFnKind::Free) != AllocFnKind::Unknown)
parts.push_back("free");
if ((Kind & AllocFnKind::Uninitialized) != AllocFnKind::Unknown)
parts.push_back("uninitialized");
if ((Kind & AllocFnKind::Zeroed) != AllocFnKind::Unknown)
parts.push_back("zeroed");
if ((Kind & AllocFnKind::Aligned) != AllocFnKind::Unknown)
parts.push_back("aligned");
return ("allockind(\"" +
Twine(llvm::join(parts.begin(), parts.end(), ",")) + "\")")
.str();
}
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-01-31 20:59:05 +00: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-05 22:37:24 +00: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-01-31 20:59:05 +00: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 11:44:06 +00:00
{
raw_string_ostream OS(Result);
[IR] Simplify code to print string attributes a bit. NFC.
2020-04-26 13:06:50 +02: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 11:44:06 +00:00
}
Remove some dead code, improve some asserts, and other assorted changes. No functionality change. llvm-svn: 174132
2013-02-01 01:04:27 +00: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-01-31 20:59:05 +00: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 03:20:31 +00: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-02 23:42:30 +00:00
}
Verify the LLVMContext that an Attribute belongs to. Attributes don't know their parent Context, adding this would make Attribute larger. Instead, we add hasParentContext that answers whether this Attribute belongs to a particular LLVMContext by checking for itself inside the context's FoldingSet. Same with AttributeSet and AttributeList. The Verifier checks them with the Module context. Differential Revision: https://reviews.llvm.org/D99362
2021-03-24 16:13:29 -07:00
bool Attribute::hasParentContext(LLVMContext &C) const {
assert(isValid() && "invalid Attribute doesn't refer to any context");
FoldingSetNodeID ID;
pImpl->Profile(ID);
void *Unused;
return C.pImpl->AttrsSet.FindNodeOrInsertPos(ID, Unused) == pImpl;
}
Reorder some functions and add comments. No functionality change. llvm-svn: 173733
2013-01-29 00:34:06 +00: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-08 23:27:46 +00: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-17 16:04:02 -08:00
void Attribute::Profile(FoldingSetNodeID &ID) const {
ID.AddPointer(pImpl);
}
[Attributes] Determine attribute properties from TableGen data Continuing from D105763, this allows placing certain properties about attributes in the TableGen definition. In particular, we store whether an attribute applies to fn/param/ret (or a combination thereof). This information is used by the Verifier, as well as the ForceFunctionAttrs pass. I also plan to use this in LLParser, which also duplicates info on which attributes are valid where. This keeps metadata about attributes in one place, and makes it more likely that it stays in sync, rather than in various functions spread across the codebase. Differential Revision: https://reviews.llvm.org/D105780
2021-07-11 16:54:03 +02:00
enum AttributeProperty {
FnAttr = (1 << 0),
ParamAttr = (1 << 1),
RetAttr = (1 << 2),
};
#define GET_ATTR_PROP_TABLE
#include "llvm/IR/Attributes.inc"
static bool hasAttributeProperty(Attribute::AttrKind Kind,
AttributeProperty Prop) {
unsigned Index = Kind - 1;
assert(Index < sizeof(AttrPropTable) / sizeof(AttrPropTable[0]) &&
"Invalid attribute kind");
return AttrPropTable[Index] & Prop;
}
bool Attribute::canUseAsFnAttr(AttrKind Kind) {
return hasAttributeProperty(Kind, AttributeProperty::FnAttr);
}
bool Attribute::canUseAsParamAttr(AttrKind Kind) {
return hasAttributeProperty(Kind, AttributeProperty::ParamAttr);
}
bool Attribute::canUseAsRetAttr(AttrKind Kind) {
return hasAttributeProperty(Kind, AttributeProperty::RetAttr);
}
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-26 21:07:29 +00: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-05 22:37:24 +00: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 01:38:39 +00: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 00:06:56 +00: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-05 22:37:24 +00: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-04 20:54:35 +00: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 01:38:39 +00: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-05 22:37:24 +00: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-30 18:48:23 +00: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 12:13:16 +00: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-05 22:37:24 +00:00
}
Remove some dead code, improve some asserts, and other assorted changes. No functionality change. llvm-svn: 174132
2013-02-01 01:04:27 +00: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-05 22:37:24 +00: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 06:51:55 +00: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-05 22:37:24 +00: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 00:06:56 +00:00
Normalize interaction with boolean attributes Such attributes can either be unset, or set to "true" or "false" (as string). throughout the codebase, this led to inelegant checks ranging from if (Fn->getFnAttribute("no-jump-tables").getValueAsString() == "true") to if (Fn->hasAttribute("no-jump-tables") && Fn->getFnAttribute("no-jump-tables").getValueAsString() == "true") Introduce a getValueAsBool that normalize the check, with the following behavior: no attributes or attribute set to "false" => return false attribute set to "true" => return true Differential Revision: https://reviews.llvm.org/D99299
2021-03-24 16:45:04 -04:00
bool AttributeImpl::getValueAsBool() const {
assert(getValueAsString().empty() || getValueAsString() == "false" || getValueAsString() == "true");
return getValueAsString() == "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-05 22:37:24 +00: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 12:13:16 +00: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-05 22:37:24 +00: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 00:06:56 +00: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-05 22:37:24 +00: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 12:13:16 +00: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-05 22:37:24 +00: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 00:06:56 +00: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-30 18:48:23 +00: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-05 22:37:24 +00: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 14:43:02 +03:00
if (this == &AI)
return false;
[Attributes] Simplify attribute sorting (NFCI) It's not necessary to explicitly sort by enum/int/type attribute, as the attribute kinds are already sorted this way. We can directly sort by kind.
2021-07-12 21:08:41 +02: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-05 22:37:24 +00:00
// This sorts the attributes with Attribute::AttrKinds coming first (sorted
// relative to their enum value) and then strings.
[Attributes] Simplify attribute sorting (NFCI) It's not necessary to explicitly sort by enum/int/type attribute, as the attribute kinds are already sorted this way. We can directly sort by kind.
2021-07-12 21:08:41 +02:00
if (!isStringAttribute()) {
if (AI.isStringAttribute())
return true;
if (getKindAsEnum() != AI.getKindAsEnum())
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-30 18:48:23 +00:00
return getKindAsEnum() < AI.getKindAsEnum();
[Attributes] Simplify attribute sorting (NFCI) It's not necessary to explicitly sort by enum/int/type attribute, as the attribute kinds are already sorted this way. We can directly sort by kind.
2021-07-12 21:08:41 +02:00
assert(!AI.isEnumAttribute() && "Non-unique attribute");
assert(!AI.isTypeAttribute() && "Comparison of types would be unstable");
// TODO: Is this actually needed?
assert(AI.isIntAttribute() && "Only possibility left");
return getValueAsInt() < AI.getValueAsInt();
Revert "Simplify the attributes '<' comparison function." This reverts commit 82c101153fe7b35bce48781fab038e1b8f31a7bd. llvm-svn: 175250
2013-02-15 04:15:55 +00:00
}
[Attributes] Simplify attribute sorting (NFCI) It's not necessary to explicitly sort by enum/int/type attribute, as the attribute kinds are already sorted this way. We can directly sort by kind.
2021-07-12 21:08:41 +02:00
if (!AI.isStringAttribute())
return false;
Simplify the 'operator<' for the attribute object. llvm-svn: 175252
2013-02-15 05:25:26 +00: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 00:06:56 +00: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 00:38:00 +00: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 12:28:08 +00: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-23 17:01:48 +00: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 12:28:08 +00:00
if (hasAttribute(Kind)) return *this;
Use a sorted array instead of a map to store AttrBuilder string attributes Using and std::map<SmallString, SmallString> for target dependent attributes is inefficient: it makes its constructor slightly heavier, and involves extra allocation for each new string attribute. Storing the attribute key/value as strings implies extra allocation/copy step. Use a sorted vector instead. Given the low number of attributes generally involved, this is cheaper, as showcased by https://llvm-compile-time-tracker.com/compare.php?from=5de322295f4ade692dc4f1823ae4450ad3c48af2&to=05bc480bf641a9e3b466619af43a2d123ee3f71d&stat=instructions Differential Revision: https://reviews.llvm.org/D116599
2022-01-03 13:32:19 -05:00
AttrBuilder B(C);
[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 12:28:08 +00:00
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-23 17:01:48 +00:00
StringRef Value) const {
Use a sorted array instead of a map to store AttrBuilder string attributes Using and std::map<SmallString, SmallString> for target dependent attributes is inefficient: it makes its constructor slightly heavier, and involves extra allocation for each new string attribute. Storing the attribute key/value as strings implies extra allocation/copy step. Use a sorted vector instead. Given the low number of attributes generally involved, this is cheaper, as showcased by https://llvm-compile-time-tracker.com/compare.php?from=5de322295f4ade692dc4f1823ae4450ad3c48af2&to=05bc480bf641a9e3b466619af43a2d123ee3f71d&stat=instructions Differential Revision: https://reviews.llvm.org/D116599
2022-01-03 13:32:19 -05:00
AttrBuilder B(C);
[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 12:28:08 +00:00
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;
[Attributes] Make attribute addition behavior consistent Currently, the behavior when adding an attribute with the same key as an existing attribute is inconsistent, depending on the type of the attribute and the method used to add it. When going through AttrBuilder::addAttribute(), the new attribute always overwrites the old one. When going through AttrBuilder::merge() the new attribute overwrites the existing one if it is a string attribute, but keeps the existing one for int and type attributes. One particular API also asserts that you can't overwrite an align attribute, but does not handle any of the other int, type or string attributes. This patch makes the behavior consistent by always overwriting with the new attribute, which is the behavior I would intuitively expect. Two tests are affected, which now make a different (but equally valid) choice. Those tests could be improved by taking the maximum deref bytes, but I haven't bothered with that, since this is testing a degenerate case -- the important bit is that it doesn't crash. Differential Revision: https://reviews.llvm.org/D117552
2022-01-18 11:55:28 +01:00
AttrBuilder B(C, *this);
B.merge(AttrBuilder(C, AS));
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 12:28:08 +00:00
}
AttributeSet AttributeSet::removeAttribute(LLVMContext &C,
Attribute::AttrKind Kind) const {
if (!hasAttribute(Kind)) return *this;
Use a sorted array instead of a map to store AttrBuilder string attributes Using and std::map<SmallString, SmallString> for target dependent attributes is inefficient: it makes its constructor slightly heavier, and involves extra allocation for each new string attribute. Storing the attribute key/value as strings implies extra allocation/copy step. Use a sorted vector instead. Given the low number of attributes generally involved, this is cheaper, as showcased by https://llvm-compile-time-tracker.com/compare.php?from=5de322295f4ade692dc4f1823ae4450ad3c48af2&to=05bc480bf641a9e3b466619af43a2d123ee3f71d&stat=instructions Differential Revision: https://reviews.llvm.org/D116599
2022-01-03 13:32:19 -05:00
AttrBuilder B(C, *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-17 19:15:21 +00:00
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 12:28:08 +00:00
}
AttributeSet AttributeSet::removeAttribute(LLVMContext &C,
StringRef Kind) const {
if (!hasAttribute(Kind)) return *this;
Use a sorted array instead of a map to store AttrBuilder string attributes Using and std::map<SmallString, SmallString> for target dependent attributes is inefficient: it makes its constructor slightly heavier, and involves extra allocation for each new string attribute. Storing the attribute key/value as strings implies extra allocation/copy step. Use a sorted vector instead. Given the low number of attributes generally involved, this is cheaper, as showcased by https://llvm-compile-time-tracker.com/compare.php?from=5de322295f4ade692dc4f1823ae4450ad3c48af2&to=05bc480bf641a9e3b466619af43a2d123ee3f71d&stat=instructions Differential Revision: https://reviews.llvm.org/D116599
2022-01-03 13:32:19 -05:00
AttrBuilder B(C, *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-17 19:15:21 +00:00
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 12:28:08 +00:00
}
AttributeSet AttributeSet::removeAttributes(LLVMContext &C,
Introduce the AttributeMask class This class is solely used as a lightweight and clean way to build a set of attributes to be removed from an AttrBuilder. Previously AttrBuilder was used both for building and removing, which introduced odd situation like creation of Attribute with dummy value because the only relevant part was the attribute kind. Differential Revision: https://reviews.llvm.org/D116110
2022-01-04 09:44:47 +01:00
const AttributeMask &Attrs) const {
Use a sorted array instead of a map to store AttrBuilder string attributes Using and std::map<SmallString, SmallString> for target dependent attributes is inefficient: it makes its constructor slightly heavier, and involves extra allocation for each new string attribute. Storing the attribute key/value as strings implies extra allocation/copy step. Use a sorted vector instead. Given the low number of attributes generally involved, this is cheaper, as showcased by https://llvm-compile-time-tracker.com/compare.php?from=5de322295f4ade692dc4f1823ae4450ad3c48af2&to=05bc480bf641a9e3b466619af43a2d123ee3f71d&stat=instructions Differential Revision: https://reviews.llvm.org/D116599
2022-01-03 13:32:19 -05:00
AttrBuilder B(C, *this);
[IR] Optimize no-op removal from AttributeSet (NFC) When removing an AttrBuilder from an AttributeSet, first check whether there is any overlap. If nothing is being removed, we can directly return the original set.
2021-05-22 18:53:17 +02:00
// If there is nothing to remove, directly return the original set.
if (!B.overlaps(Attrs))
return *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 12:28:08 +00:00
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 00:38:00 +00: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-15 21:57:41 +00: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 00:38:00 +00: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-15 21:57:41 +00: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 00:38:00 +00: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 09:51:06 +00: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 00:38:00 +00: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 09:51:06 +00: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 00:38:00 +00: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-05 16:58:47 -04:00
Type *AttributeSet::getByRefType() const {
[Attributes] Use single method to fetch type from AttributeSet (NFC) While it is nice to have separate methods in the public AttributeSet API, we can fetch the type from the internal AttributeSetNode using a generic API for all type attribute kinds.
2021-07-14 21:09:06 +02:00
return SetNode ? SetNode->getAttributeType(Attribute::ByRef) : 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-05 16:58:47 -04: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-30 18:48:23 +00:00
Type *AttributeSet::getByValType() const {
[Attributes] Use single method to fetch type from AttributeSet (NFC) While it is nice to have separate methods in the public AttributeSet API, we can fetch the type from the internal AttributeSetNode using a generic API for all type attribute kinds.
2021-07-14 21:09:06 +02:00
return SetNode ? SetNode->getAttributeType(Attribute::ByVal) : 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-30 18:48:23 +00: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 09:33:55 -04:00
Type *AttributeSet::getStructRetType() const {
[Attributes] Use single method to fetch type from AttributeSet (NFC) While it is nice to have separate methods in the public AttributeSet API, we can fetch the type from the internal AttributeSetNode using a generic API for all type attribute kinds.
2021-07-14 21:09:06 +02:00
return SetNode ? SetNode->getAttributeType(Attribute::StructRet) : 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 09:33:55 -04:00
}
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-14 14:16:53 -08:00
Type *AttributeSet::getPreallocatedType() const {
[Attributes] Use single method to fetch type from AttributeSet (NFC) While it is nice to have separate methods in the public AttributeSet API, we can fetch the type from the internal AttributeSetNode using a generic API for all type attribute kinds.
2021-07-14 21:09:06 +02:00
return SetNode ? SetNode->getAttributeType(Attribute::Preallocated) : 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-14 14:16:53 -08:00
}
Reapply "OpaquePtr: Turn inalloca into a type attribute" This reverts commit 07e46367baeca96d84b03fa215b41775f69d5989.
2021-03-29 08:42:23 -04:00
Type *AttributeSet::getInAllocaType() const {
[Attributes] Use single method to fetch type from AttributeSet (NFC) While it is nice to have separate methods in the public AttributeSet API, we can fetch the type from the internal AttributeSetNode using a generic API for all type attribute kinds.
2021-07-14 21:09:06 +02:00
return SetNode ? SetNode->getAttributeType(Attribute::InAlloca) : nullptr;
Reapply "OpaquePtr: Turn inalloca into a type attribute" This reverts commit 07e46367baeca96d84b03fa215b41775f69d5989.
2021-03-29 08:42:23 -04:00
}
[IR] Add elementtype attribute This implements the elementtype attribute specified in D105407. It just adds the attribute and the specified verifier rules, but doesn't yet make use of it anywhere. Differential Revision: https://reviews.llvm.org/D106008
2021-07-07 22:29:43 +02:00
Type *AttributeSet::getElementType() const {
return SetNode ? SetNode->getAttributeType(Attribute::ElementType) : 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 00:38:00 +00: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-12 23:57:37 +00: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 00:38:00 +00:00
}
[IR] Split vscale_range interface Interface is split from: std::pair<unsigned, unsigned> getVScaleRangeArgs() into separate functions for min/max: unsigned getVScaleRangeMin(); Optional<unsigned> getVScaleRangeMax(); Reviewed By: sdesmalen, paulwalker-arm Differential Revision: https://reviews.llvm.org/D114075
2021-12-07 09:53:16 +00:00
unsigned AttributeSet::getVScaleRangeMin() const {
return SetNode ? SetNode->getVScaleRangeMin() : 1;
}
Optional<unsigned> AttributeSet::getVScaleRangeMax() const {
return SetNode ? SetNode->getVScaleRangeMax() : None;
[IR] Add vscale_range IR function attribute This attribute represents the minimum and maximum values vscale can take. For now this attribute is not hooked up to anything during codegen, this will be added in the future when such codegen is considered stable. Additionally hook up the -msve-vector-bits=<x> clang option to emit this attribute. Differential Revision: https://reviews.llvm.org/D98030
2021-03-03 13:53:30 +00:00
}
Extend the `uwtable` attribute with unwind table kind We have the `clang -cc1` command-line option `-funwind-tables=1|2` and the codegen option `VALUE_CODEGENOPT(UnwindTables, 2, 0) ///< Unwind tables (1) or asynchronous unwind tables (2)`. However, this is encoded in LLVM IR by the presence or the absence of the `uwtable` attribute, i.e. we lose the information whether to generate want just some unwind tables or asynchronous unwind tables. Asynchronous unwind tables take more space in the runtime image, I'd estimate something like 80-90% more, as the difference is adding roughly the same number of CFI directives as for prologues, only a bit simpler (e.g. `.cfi_offset reg, off` vs. `.cfi_restore reg`). Or even more, if you consider tail duplication of epilogue blocks. Asynchronous unwind tables could also restrict code generation to having only a finite number of frame pointer adjustments (an example of *not* having a finite number of `SP` adjustments is on AArch64 when untagging the stack (MTE) in some cases the compiler can modify `SP` in a loop). Having the CFI precise up to an instruction generally also means one cannot bundle together CFI instructions once the prologue is done, they need to be interspersed with ordinary instructions, which means extra `DW_CFA_advance_loc` commands, further increasing the unwind tables size. That is to say, async unwind tables impose a non-negligible overhead, yet for the most common use cases (like C++ exceptions), they are not even needed. This patch extends the `uwtable` attribute with an optional value: - `uwtable` (default to `async`) - `uwtable(sync)`, synchronous unwind tables - `uwtable(async)`, asynchronous (instruction precise) unwind tables Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D114543
2022-02-14 13:41:34 +00:00
UWTableKind AttributeSet::getUWTableKind() const {
return SetNode ? SetNode->getUWTableKind() : UWTableKind::None;
}
attributes: introduce allockind attr for describing allocator fn behavior I chose to encode the allockind information in a string constant because otherwise we would get a bit of an explosion of keywords to deal with the possible permutations of allocation function types. I'm not sure that CodeGen.h is the correct place for this enum, but it seemed to kind of match the UWTableKind enum so I put it in the same place. Constructive suggestions on a better location most certainly encouraged. Differential Revision: https://reviews.llvm.org/D123088
2022-03-29 11:14:07 -04:00
AllocFnKind AttributeSet::getAllocKind() const {
return SetNode ? SetNode->getAllocKind() : AllocFnKind::Unknown;
}
[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 00:38:00 +00:00
std::string AttributeSet::getAsString(bool InAttrGrp) const {
return SetNode ? SetNode->getAsString(InAttrGrp) : "";
}
Verify the LLVMContext that an Attribute belongs to. Attributes don't know their parent Context, adding this would make Attribute larger. Instead, we add hasParentContext that answers whether this Attribute belongs to a particular LLVMContext by checking for itself inside the context's FoldingSet. Same with AttributeSet and AttributeList. The Verifier checks them with the Module context. Differential Revision: https://reviews.llvm.org/D99362
2021-03-24 16:13:29 -07:00
bool AttributeSet::hasParentContext(LLVMContext &C) const {
assert(hasAttributes() && "empty AttributeSet doesn't refer to any context");
FoldingSetNodeID ID;
SetNode->Profile(ID);
void *Unused;
return C.pImpl->AttrsSetNodes.FindNodeOrInsertPos(ID, Unused) == SetNode;
}
[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 00:38:00 +00:00
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 14:32:27 +00: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 12:28:08 +00: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 00:06:56 +00: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-10 23:46:08 +00: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 00:29:03 +00: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-10 23:46:08 +00:00
// There's memory after the node where we can store the entries in.
Use llvm::copy. NFC llvm-svn: 347126
2018-11-17 01:44:25 +00: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-10 23:46:08 +00: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-17 21:57:58 +01: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-14 23:46:18 +02: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 12:21:21 +02: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-14 23:46:18 +02: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-10 23:46:08 +00: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 00:06:56 +00: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 16:52:53 +02: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 06:08:46 +00: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 00:06:56 +00: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 16:52:53 +02: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 00:06:56 +00: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 16:52:53 +02: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-17 21:57:58 +01:00
for (const auto &Attr : SortedAttrs)
Minor cleanup of Attribute code. NFC. llvm-svn: 255751
2015-12-16 05:21:02 +00: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 00:06:56 +00: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 12:13:16 +00: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-05 22:57:34 +00: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 12:13:16 +00: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 00:06:56 +00: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-21 16:57:19 +00: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 00:06:56 +00: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-10 23:31:05 +00:00
AttributeSetNode *AttributeSetNode::get(LLVMContext &C, const AttrBuilder &B) {
[AttrBuilder] Change storage to sorted vector (NFC) This follows up on the work in D116599, which changed AttrBuilder to store string attributes as SmallVector<Attribute>. This patch changes the implementation to store *all* attributes as a sorted vector. This both makes the implementation simpler and improves compile-time. We get a -0.5% geomean compile-time improvement on CTMark at O0. Differential Revision: https://reviews.llvm.org/D117558
2022-01-15 10:05:22 +01:00
return getSorted(C, B.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-10 23:31:05 +00:00
}
Add some accessor and query methods for retrieving Attribute objects and such. llvm-svn: 175046
2013-02-13 08:42:21 +00: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 12:21:21 +02:00
return StringAttrs.count(Kind);
Add some accessor and query methods for retrieving Attribute objects and such. llvm-svn: 175046
2013-02-13 08:42:21 +00: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-26 20:03:29 +02: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 08:42:21 +00: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-26 20:03:29 +02: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 00:47:31 +00:00
return {};
Add some accessor and query methods for retrieving Attribute objects and such. llvm-svn: 175046
2013-02-13 08:42:21 +00: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 12:21:21 +02:00
return StringAttrs.lookup(Kind);
Add some accessor and query methods for retrieving Attribute objects and such. llvm-svn: 175046
2013-02-13 08:42:21 +00: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 09:51:06 +00: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-26 20:03:29 +02: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 09:51:06 +00: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 03:20:31 +00: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 09:51:06 +00: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-26 20:03:29 +02: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 09:51:06 +00: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 03:20:31 +00:00
}
[Attributes] Use single method to fetch type from AttributeSet (NFC) While it is nice to have separate methods in the public AttributeSet API, we can fetch the type from the internal AttributeSetNode using a generic API for all type attribute kinds.
2021-07-14 21:09:06 +02:00
Type *AttributeSetNode::getAttributeType(Attribute::AttrKind Kind) const {
if (auto A = findEnumAttribute(Kind))
Reapply "OpaquePtr: Turn inalloca into a type attribute" This reverts commit 07e46367baeca96d84b03fa215b41775f69d5989.
2021-03-29 08:42:23 -04:00
return A->getValueAsType();
return 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 15:51:28 +00: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-26 20:03:29 +02: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 15:51:28 +00: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-06 17:41:54 +00: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-26 20:03:29 +02: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-06 17:41:54 +00: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 01:05:35 +00: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-26 20:03:29 +02: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 01:05:35 +00:00
return std::make_pair(0, 0);
}
[IR] Split vscale_range interface Interface is split from: std::pair<unsigned, unsigned> getVScaleRangeArgs() into separate functions for min/max: unsigned getVScaleRangeMin(); Optional<unsigned> getVScaleRangeMax(); Reviewed By: sdesmalen, paulwalker-arm Differential Revision: https://reviews.llvm.org/D114075
2021-12-07 09:53:16 +00:00
unsigned AttributeSetNode::getVScaleRangeMin() const {
[IR] Add vscale_range IR function attribute This attribute represents the minimum and maximum values vscale can take. For now this attribute is not hooked up to anything during codegen, this will be added in the future when such codegen is considered stable. Additionally hook up the -msve-vector-bits=<x> clang option to emit this attribute. Differential Revision: https://reviews.llvm.org/D98030
2021-03-03 13:53:30 +00:00
if (auto A = findEnumAttribute(Attribute::VScaleRange))
[IR] Split vscale_range interface Interface is split from: std::pair<unsigned, unsigned> getVScaleRangeArgs() into separate functions for min/max: unsigned getVScaleRangeMin(); Optional<unsigned> getVScaleRangeMax(); Reviewed By: sdesmalen, paulwalker-arm Differential Revision: https://reviews.llvm.org/D114075
2021-12-07 09:53:16 +00:00
return A->getVScaleRangeMin();
return 1;
}
Optional<unsigned> AttributeSetNode::getVScaleRangeMax() const {
if (auto A = findEnumAttribute(Attribute::VScaleRange))
return A->getVScaleRangeMax();
return None;
[IR] Add vscale_range IR function attribute This attribute represents the minimum and maximum values vscale can take. For now this attribute is not hooked up to anything during codegen, this will be added in the future when such codegen is considered stable. Additionally hook up the -msve-vector-bits=<x> clang option to emit this attribute. Differential Revision: https://reviews.llvm.org/D98030
2021-03-03 13:53:30 +00:00
}
Extend the `uwtable` attribute with unwind table kind We have the `clang -cc1` command-line option `-funwind-tables=1|2` and the codegen option `VALUE_CODEGENOPT(UnwindTables, 2, 0) ///< Unwind tables (1) or asynchronous unwind tables (2)`. However, this is encoded in LLVM IR by the presence or the absence of the `uwtable` attribute, i.e. we lose the information whether to generate want just some unwind tables or asynchronous unwind tables. Asynchronous unwind tables take more space in the runtime image, I'd estimate something like 80-90% more, as the difference is adding roughly the same number of CFI directives as for prologues, only a bit simpler (e.g. `.cfi_offset reg, off` vs. `.cfi_restore reg`). Or even more, if you consider tail duplication of epilogue blocks. Asynchronous unwind tables could also restrict code generation to having only a finite number of frame pointer adjustments (an example of *not* having a finite number of `SP` adjustments is on AArch64 when untagging the stack (MTE) in some cases the compiler can modify `SP` in a loop). Having the CFI precise up to an instruction generally also means one cannot bundle together CFI instructions once the prologue is done, they need to be interspersed with ordinary instructions, which means extra `DW_CFA_advance_loc` commands, further increasing the unwind tables size. That is to say, async unwind tables impose a non-negligible overhead, yet for the most common use cases (like C++ exceptions), they are not even needed. This patch extends the `uwtable` attribute with an optional value: - `uwtable` (default to `async`) - `uwtable(sync)`, synchronous unwind tables - `uwtable(async)`, asynchronous (instruction precise) unwind tables Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D114543
2022-02-14 13:41:34 +00:00
UWTableKind AttributeSetNode::getUWTableKind() const {
if (auto A = findEnumAttribute(Attribute::UWTable))
return A->getUWTableKind();
return UWTableKind::None;
}
attributes: introduce allockind attr for describing allocator fn behavior I chose to encode the allockind information in a string constant because otherwise we would get a bit of an explosion of keywords to deal with the possible permutations of allocation function types. I'm not sure that CodeGen.h is the correct place for this enum, but it seemed to kind of match the UWTableKind enum so I put it in the same place. Constructive suggestions on a better location most certainly encouraged. Differential Revision: https://reviews.llvm.org/D123088
2022-03-29 11:14:07 -04:00
AllocFnKind AttributeSetNode::getAllocKind() const {
if (auto A = findEnumAttribute(Attribute::AllocKind))
return A->getAllocKind();
return AllocFnKind::Unknown;
}
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 13:07:03 +00: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 11:43:21 +00: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 12:13:16 +00: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 13:07:03 +00: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 03:20:31 +00: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-12 17:45:29 +00: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-21 16:57:19 +00: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-12 17:45:29 +00: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 01:40:38 +00: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-23 22:25:04 +02: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-17 18:25:56 +02: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-23 22:25:04 +02: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-23 17:01:48 +00:00
}
[IR] AttributeList::getContext has a single user, remove it.
2020-05-01 14:18:29 +02: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-23 17:01:48 +00:00
assert(!Sets.empty() && "pointless AttributeListImpl");
[IR] Sink some AttributeListImpl methods out of headers NFC llvm-svn: 299906
2017-04-11 00:16:00 +00:00
// There's memory after the node where we can store the entries in.
Use llvm::copy. NFC llvm-svn: 347126
2018-11-17 01:44:25 +00:00
llvm::copy(Sets, getTrailingObjects<AttributeSet>());
[IR] Sink some AttributeListImpl methods out of headers NFC llvm-svn: 299906
2017-04-11 00:16:00 +00: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-14 22:49:57 +02: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-17 18:25:56 +02: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-14 23:46:18 +02: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-14 22:49:57 +02: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 00:16:00 +00: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-23 17:01:48 +00:00
Profile(ID, makeArrayRef(begin(), end()));
[IR] Sink some AttributeListImpl methods out of headers NFC llvm-svn: 299906
2017-04-11 00:16:00 +00: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-23 17:01:48 +00: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 00:16:00 +00: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-14 22:49:57 +02: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 14:32:27 +00: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-21 16:57:19 +00: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-02 22:34:30 +00: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 02:02:38 +00: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-02 22:34:30 +00:00
In the AttributeSetImpl c'tor, fill in the AttrNodes data structure with the attributes being passed in. llvm-svn: 173618
2013-01-27 12:50:02 +00: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-21 16:57:19 +00: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 12:50:02 +00: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-23 17:01:48 +00: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-10 23:31:05 +00:00
Reorder some functions and add comments. No functionality change. llvm-svn: 173733
2013-01-29 00:34:06 +00: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-23 17:01:48 +00:00
AttributeListImpl::Profile(ID, AttrSets);
Cleanup whitespace. llvm-svn: 166013
2012-10-16 06:01:44 +00: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 05:09:20 +00: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-21 16:57:19 +00:00
AttributeListImpl *PA =
pImpl->AttrsLists.FindNodeOrInsertPos(ID, InsertPoint);
Cleanup whitespace. llvm-svn: 166013
2012-10-16 06:01:44 +00: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-02 23:42:30 +00: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 05:09:20 +00: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-21 16:57:19 +00:00
// Coallocate entries after the AttributeListImpl itself.
[IR] Make Attributes and AttributeLists trivially destructible and BumpPtrAllocate them
2020-05-01 14:12:17 +02: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 14:18:29 +02: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 05:09:20 +00: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-02 23:42:30 +00:00
}
Cleanup whitespace. llvm-svn: 166013
2012-10-16 06:01:44 +00: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-25 21:00:45 +00: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-21 16:57:19 +00: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-02 23:42:30 +00: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-21 16:57:19 +00: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-28 21:55:20 +00: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 00:47:31 +00: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-28 21:55:20 +00:00
Use llvm::less_first (NFC)
2022-06-04 21:23:18 -07:00
assert(llvm::is_sorted(Attrs, llvm::less_first()) &&
[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 14:46:41 +03:00
"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-28 13:02:42 -07: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-11 21:15:00 +00: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-28 21:55:20 +00:00
Try to appease some broken compilers by using 'unsigned' instead of 'uint64_t'. llvm-svn: 173725
2013-01-28 22:33:39 +00: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-28 21:55:20 +00: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 00:38:00 +00: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 00:00:09 +00: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-28 21:55:20 +00:00
E = Attrs.end(); I != E; ) {
Try to appease some broken compilers by using 'unsigned' instead of 'uint64_t'. llvm-svn: 173725
2013-01-28 22:33:39 +00: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-28 21:55:20 +00: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 15:18:16 +00: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-28 21:55:20 +00: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 00:38:00 +00: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-28 21:55:20 +00: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-23 17:01:48 +00: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-28 21:55:20 +00: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-21 16:57:19 +00: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 00:38:00 +00: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-28 21:55:20 +00: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 00:47:31 +00: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-28 21:55:20 +00:00
Use llvm::less_first (NFC)
2022-06-04 21:23:18 -07:00
assert(llvm::is_sorted(Attrs, llvm::less_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-23 17:01:48 +00:00
"Misordered Attributes list!");
[IR] Fix some Clang-tidy modernize-use-auto warnings; other minor fixes (NFC). llvm-svn: 328850
2018-03-30 00:47:31 +00: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-23 17:01:48 +00: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-16 17:05:01 +00: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-23 17:01:48 +00: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-17 21:57:58 +01: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-23 17:01:48 +00: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-28 21:55:20 +00: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 00:58:09 +00: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-23 17:01:48 +00: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-10 23:31:05 +00: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-23 17:01:48 +00: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 00:47:31 +00: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-23 17:01:48 +00: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-06 18: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-23 17:01:48 +00: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-10 23:31:05 +00: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-21 16:57:19 +00:00
AttributeList AttributeList::get(LLVMContext &C, unsigned Index,
[Attributes] Add AttributeList ctor from AttributeSet (NFC) It was already possible to create an AttributeList from an Index and an AttributeSet. However, this would actually end up using the implicit constructor on AttrBuilder, thus doing an unnecessary conversion from AttributeSet to AttrBuilder to AttributeSet. Instead we can accept the AttributeSet directly, as that is what we need anyway.
2021-12-18 14:56:12 +01:00
AttributeSet Attrs) {
if (!Attrs.hasAttributes())
[IR] Fix some Clang-tidy modernize-use-auto warnings; other minor fixes (NFC). llvm-svn: 328850
2018-03-30 00:47:31 +00: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-23 17:01:48 +00:00
Index = attrIdxToArrayIdx(Index);
SmallVector<AttributeSet, 8> AttrSets(Index + 1);
[Attributes] Add AttributeList ctor from AttributeSet (NFC) It was already possible to create an AttributeList from an Index and an AttributeSet. However, this would actually end up using the implicit constructor on AttrBuilder, thus doing an unnecessary conversion from AttributeSet to AttrBuilder to AttributeSet. Instead we can accept the AttributeSet directly, as that is what we need anyway.
2021-12-18 14:56:12 +01:00
AttrSets[Index] = 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-23 17:01:48 +00:00
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 01:36:54 +00:00
}
[Attributes] Add AttributeList ctor from AttributeSet (NFC) It was already possible to create an AttributeList from an Index and an AttributeSet. However, this would actually end up using the implicit constructor on AttrBuilder, thus doing an unnecessary conversion from AttributeSet to AttrBuilder to AttributeSet. Instead we can accept the AttributeSet directly, as that is what we need anyway.
2021-12-18 14:56:12 +01:00
AttributeList AttributeList::get(LLVMContext &C, unsigned Index,
const AttrBuilder &B) {
return get(C, Index, AttributeSet::get(C, B));
}
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-21 16:57:19 +00: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-28 22:33:39 +00: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 00:47:31 +00:00
for (const auto K : Kinds)
Use range algorithms instead of unpacking begin/end No functionality change is intended. llvm-svn: 278417
2016-08-11 21:15:00 +00: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-28 21:55:20 +00: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 06:14:59 +00: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-27 16:02:15 -04: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-21 16:57:19 +00: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-15 17:50:39 +00: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-17 21:57:58 +01:00
for (const auto &K : Kinds)
Use range algorithms instead of unpacking begin/end No functionality change is intended. llvm-svn: 278417
2016-08-11 21:15:00 +00: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-15 17:50:39 +00: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-21 16:57:19 +00: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 00:47:31 +00: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-23 17:01:48 +00: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-17 21:57:58 +01: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-23 17:01:48 +00: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 14:24:06 +00: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 00:47:31 +00: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 14:24:06 +00: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-23 17:01:48 +00:00
SmallVector<AttributeSet, 8> NewAttrSets(MaxSize);
for (unsigned I = 0; I < MaxSize; ++I) {
Use a sorted array instead of a map to store AttrBuilder string attributes Using and std::map<SmallString, SmallString> for target dependent attributes is inefficient: it makes its constructor slightly heavier, and involves extra allocation for each new string attribute. Storing the attribute key/value as strings implies extra allocation/copy step. Use a sorted vector instead. Given the low number of attributes generally involved, this is cheaper, as showcased by https://llvm-compile-time-tracker.com/compare.php?from=5de322295f4ade692dc4f1823ae4450ad3c48af2&to=05bc480bf641a9e3b466619af43a2d123ee3f71d&stat=instructions Differential Revision: https://reviews.llvm.org/D116599
2022-01-03 13:32:19 -05:00
AttrBuilder CurBuilder(C);
[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-17 21:57:58 +01:00
for (const auto &List : Attrs)
Use a sorted array instead of a map to store AttrBuilder string attributes Using and std::map<SmallString, SmallString> for target dependent attributes is inefficient: it makes its constructor slightly heavier, and involves extra allocation for each new string attribute. Storing the attribute key/value as strings implies extra allocation/copy step. Use a sorted vector instead. Given the low number of attributes generally involved, this is cheaper, as showcased by https://llvm-compile-time-tracker.com/compare.php?from=5de322295f4ade692dc4f1823ae4450ad3c48af2&to=05bc480bf641a9e3b466619af43a2d123ee3f71d&stat=instructions Differential Revision: https://reviews.llvm.org/D116599
2022-01-03 13:32:19 -05:00
CurBuilder.merge(AttrBuilder(C, List.getAttributes(I - 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-23 17:01:48 +00:00
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-25 23:09:36 +00: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-23 17:01:48 +00: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-02 23:42:30 +00:00
}
[NFC] Rename attribute methods that work with indexes This is part one of a couple of patches to fully rename these methods. I've made the mistake of assuming that these indexes are for parameters multiple times, but actually they're based off of a weird indexing scheme AttributeList::AttrIndex where 0 is the return value and ~0 is the function. Hopefully renaming these methods will make this clearer. Ideally users should use more specific methods like AttributeList::getFnAttr(). This patch simply adds the name that we want in the end. This is so the removal of the methods with the original names happens in a separate change to make it easier for downstream users. This touches all relevant methods in AttributeList, CallBase, and Function. Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D108788
2021-08-20 10:49:36 -07:00
AttributeList
AttributeList::addAttributeAtIndex(LLVMContext &C, unsigned Index,
Attribute::AttrKind Kind) const {
if (hasAttributeAtIndex(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 10:38:36 +01: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));
[NFC] Rename attribute methods that work with indexes This is part one of a couple of patches to fully rename these methods. I've made the mistake of assuming that these indexes are for parameters multiple times, but actually they're based off of a weird indexing scheme AttributeList::AttrIndex where 0 is the return value and ~0 is the function. Hopefully renaming these methods will make this clearer. Ideally users should use more specific methods like AttributeList::getFnAttr(). This patch simply adds the name that we want in the end. This is so the removal of the methods with the original names happens in a separate change to make it easier for downstream users. This touches all relevant methods in AttributeList, CallBase, and Function. Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D108788
2021-08-20 10:49:36 -07:00
return setAttributesAtIndex(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-13 20:20:08 +00:00
}
[NFC] Rename attribute methods that work with indexes This is part one of a couple of patches to fully rename these methods. I've made the mistake of assuming that these indexes are for parameters multiple times, but actually they're based off of a weird indexing scheme AttributeList::AttrIndex where 0 is the return value and ~0 is the function. Hopefully renaming these methods will make this clearer. Ideally users should use more specific methods like AttributeList::getFnAttr(). This patch simply adds the name that we want in the end. This is so the removal of the methods with the original names happens in a separate change to make it easier for downstream users. This touches all relevant methods in AttributeList, CallBase, and Function. Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D108788
2021-08-20 10:49:36 -07:00
AttributeList AttributeList::addAttributeAtIndex(LLVMContext &C, unsigned Index,
StringRef Kind,
StringRef Value) const {
Use a sorted array instead of a map to store AttrBuilder string attributes Using and std::map<SmallString, SmallString> for target dependent attributes is inefficient: it makes its constructor slightly heavier, and involves extra allocation for each new string attribute. Storing the attribute key/value as strings implies extra allocation/copy step. Use a sorted vector instead. Given the low number of attributes generally involved, this is cheaper, as showcased by https://llvm-compile-time-tracker.com/compare.php?from=5de322295f4ade692dc4f1823ae4450ad3c48af2&to=05bc480bf641a9e3b466619af43a2d123ee3f71d&stat=instructions Differential Revision: https://reviews.llvm.org/D116599
2022-01-03 13:32:19 -05:00
AttrBuilder B(C);
Add a way to add a kind-value string pair to an attribute. llvm-svn: 187138
2013-07-25 18:34:24 +00:00
B.addAttribute(Kind, Value);
[NFC] Rename attribute methods that work with indexes This is part one of a couple of patches to fully rename these methods. I've made the mistake of assuming that these indexes are for parameters multiple times, but actually they're based off of a weird indexing scheme AttributeList::AttrIndex where 0 is the return value and ~0 is the function. Hopefully renaming these methods will make this clearer. Ideally users should use more specific methods like AttributeList::getFnAttr(). This patch simply adds the name that we want in the end. This is so the removal of the methods with the original names happens in a separate change to make it easier for downstream users. This touches all relevant methods in AttributeList, CallBase, and Function. Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D108788
2021-08-20 10:49:36 -07:00
return addAttributesAtIndex(C, Index, B);
Add a way to add a kind-value string pair to an attribute. llvm-svn: 187138
2013-07-25 18:34:24 +00:00
}
[NFC] Rename attribute methods that work with indexes This is part one of a couple of patches to fully rename these methods. I've made the mistake of assuming that these indexes are for parameters multiple times, but actually they're based off of a weird indexing scheme AttributeList::AttrIndex where 0 is the return value and ~0 is the function. Hopefully renaming these methods will make this clearer. Ideally users should use more specific methods like AttributeList::getFnAttr(). This patch simply adds the name that we want in the end. This is so the removal of the methods with the original names happens in a separate change to make it easier for downstream users. This touches all relevant methods in AttributeList, CallBase, and Function. Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D108788
2021-08-20 10:49:36 -07:00
AttributeList AttributeList::addAttributeAtIndex(LLVMContext &C, unsigned Index,
Attribute A) const {
Use a sorted array instead of a map to store AttrBuilder string attributes Using and std::map<SmallString, SmallString> for target dependent attributes is inefficient: it makes its constructor slightly heavier, and involves extra allocation for each new string attribute. Storing the attribute key/value as strings implies extra allocation/copy step. Use a sorted vector instead. Given the low number of attributes generally involved, this is cheaper, as showcased by https://llvm-compile-time-tracker.com/compare.php?from=5de322295f4ade692dc4f1823ae4450ad3c48af2&to=05bc480bf641a9e3b466619af43a2d123ee3f71d&stat=instructions Differential Revision: https://reviews.llvm.org/D116599
2022-01-03 13:32:19 -05:00
AttrBuilder B(C);
[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-05-31 19:23:09 +00:00
B.addAttribute(A);
[NFC] Rename attribute methods that work with indexes This is part one of a couple of patches to fully rename these methods. I've made the mistake of assuming that these indexes are for parameters multiple times, but actually they're based off of a weird indexing scheme AttributeList::AttrIndex where 0 is the return value and ~0 is the function. Hopefully renaming these methods will make this clearer. Ideally users should use more specific methods like AttributeList::getFnAttr(). This patch simply adds the name that we want in the end. This is so the removal of the methods with the original names happens in a separate change to make it easier for downstream users. This touches all relevant methods in AttributeList, CallBase, and Function. Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D108788
2021-08-20 10:49:36 -07:00
return addAttributesAtIndex(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 06:58:49 +00:00
}
[NFC] Rename attribute methods that work with indexes This is part one of a couple of patches to fully rename these methods. I've made the mistake of assuming that these indexes are for parameters multiple times, but actually they're based off of a weird indexing scheme AttributeList::AttrIndex where 0 is the return value and ~0 is the function. Hopefully renaming these methods will make this clearer. Ideally users should use more specific methods like AttributeList::getFnAttr(). This patch simply adds the name that we want in the end. This is so the removal of the methods with the original names happens in a separate change to make it easier for downstream users. This touches all relevant methods in AttributeList, CallBase, and Function. Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D108788
2021-08-20 10:49:36 -07:00
AttributeList AttributeList::setAttributesAtIndex(LLVMContext &C,
unsigned Index,
AttributeSet Attrs) const {
[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 10:38:36 +01:00
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);
}
[NFC] Rename attribute methods that work with indexes This is part one of a couple of patches to fully rename these methods. I've made the mistake of assuming that these indexes are for parameters multiple times, but actually they're based off of a weird indexing scheme AttributeList::AttrIndex where 0 is the return value and ~0 is the function. Hopefully renaming these methods will make this clearer. Ideally users should use more specific methods like AttributeList::getFnAttr(). This patch simply adds the name that we want in the end. This is so the removal of the methods with the original names happens in a separate change to make it easier for downstream users. This touches all relevant methods in AttributeList, CallBase, and Function. Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D108788
2021-08-20 10:49:36 -07:00
AttributeList AttributeList::addAttributesAtIndex(LLVMContext &C,
unsigned Index,
const AttrBuilder &B) const {
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 01:51:13 +00:00
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-10 23:31:05 +00:00
return *this;
Fix crash in AttributeList::addAttributes, add test llvm-svn: 300614
2017-04-18 22:10:18 +00: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 01:51:13 +00:00
return AttributeList::get(C, {{Index, AttributeSet::get(C, B)}});
Fix crash in AttributeList::addAttributes, add test llvm-svn: 300614
2017-04-18 22:10:18 +00:00
Use a sorted array instead of a map to store AttrBuilder string attributes Using and std::map<SmallString, SmallString> for target dependent attributes is inefficient: it makes its constructor slightly heavier, and involves extra allocation for each new string attribute. Storing the attribute key/value as strings implies extra allocation/copy step. Use a sorted vector instead. Given the low number of attributes generally involved, this is cheaper, as showcased by https://llvm-compile-time-tracker.com/compare.php?from=5de322295f4ade692dc4f1823ae4450ad3c48af2&to=05bc480bf641a9e3b466619af43a2d123ee3f71d&stat=instructions Differential Revision: https://reviews.llvm.org/D116599
2022-01-03 13:32:19 -05:00
AttrBuilder Merged(C, 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-23 17:01:48 +00:00
Merged.merge(B);
[NFC] Rename attribute methods that work with indexes This is part one of a couple of patches to fully rename these methods. I've made the mistake of assuming that these indexes are for parameters multiple times, but actually they're based off of a weird indexing scheme AttributeList::AttrIndex where 0 is the return value and ~0 is the function. Hopefully renaming these methods will make this clearer. Ideally users should use more specific methods like AttributeList::getFnAttr(). This patch simply adds the name that we want in the end. This is so the removal of the methods with the original names happens in a separate change to make it easier for downstream users. This touches all relevant methods in AttributeList, CallBase, and Function. Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D108788
2021-08-20 10:49:36 -07:00
return setAttributesAtIndex(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-10 23:31:05 +00: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-05-31 19:23:09 +00: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 14:46:41 +03: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-05-31 19:23:09 +00: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);
Use a sorted array instead of a map to store AttrBuilder string attributes Using and std::map<SmallString, SmallString> for target dependent attributes is inefficient: it makes its constructor slightly heavier, and involves extra allocation for each new string attribute. Storing the attribute key/value as strings implies extra allocation/copy step. Use a sorted vector instead. Given the low number of attributes generally involved, this is cheaper, as showcased by https://llvm-compile-time-tracker.com/compare.php?from=5de322295f4ade692dc4f1823ae4450ad3c48af2&to=05bc480bf641a9e3b466619af43a2d123ee3f71d&stat=instructions Differential Revision: https://reviews.llvm.org/D116599
2022-01-03 13:32:19 -05:00
AttrBuilder B(C, AttrSets[Index]);
[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-05-31 19:23:09 +00:00
B.addAttribute(A);
AttrSets[Index] = AttributeSet::get(C, B);
}
return getImpl(C, AttrSets);
}
[NFC] Rename attribute methods that work with indexes This is part one of a couple of patches to fully rename these methods. I've made the mistake of assuming that these indexes are for parameters multiple times, but actually they're based off of a weird indexing scheme AttributeList::AttrIndex where 0 is the return value and ~0 is the function. Hopefully renaming these methods will make this clearer. Ideally users should use more specific methods like AttributeList::getFnAttr(). This patch simply adds the name that we want in the end. This is so the removal of the methods with the original names happens in a separate change to make it easier for downstream users. This touches all relevant methods in AttributeList, CallBase, and Function. Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D108788
2021-08-20 10:49:36 -07:00
AttributeList
AttributeList::removeAttributeAtIndex(LLVMContext &C, unsigned Index,
Attribute::AttrKind Kind) const {
if (!hasAttributeAtIndex(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-17 19:15:21 +00: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 00:45:55 +00:00
}
[NFC] Rename attribute methods that work with indexes This is part one of a couple of patches to fully rename these methods. I've made the mistake of assuming that these indexes are for parameters multiple times, but actually they're based off of a weird indexing scheme AttributeList::AttrIndex where 0 is the return value and ~0 is the function. Hopefully renaming these methods will make this clearer. Ideally users should use more specific methods like AttributeList::getFnAttr(). This patch simply adds the name that we want in the end. This is so the removal of the methods with the original names happens in a separate change to make it easier for downstream users. This touches all relevant methods in AttributeList, CallBase, and Function. Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D108788
2021-08-20 10:49:36 -07:00
AttributeList AttributeList::removeAttributeAtIndex(LLVMContext &C,
unsigned Index,
StringRef Kind) const {
if (!hasAttributeAtIndex(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-17 19:15:21 +00: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-02 23:42:30 +00:00
}
Introduce the AttributeMask class This class is solely used as a lightweight and clean way to build a set of attributes to be removed from an AttrBuilder. Previously AttrBuilder was used both for building and removing, which introduced odd situation like creation of Attribute with dummy value because the only relevant part was the attribute kind. Differential Revision: https://reviews.llvm.org/D116110
2022-01-04 09:44:47 +01:00
AttributeList AttributeList::removeAttributesAtIndex(
LLVMContext &C, unsigned Index, const AttributeMask &AttrsToRemove) const {
[IR] Optimize no-op removal from AttributeList (NFC) When removing an AttrBuilder from an index of an AttributeList, directly return the original list if no attributes were actually removed.
2021-05-22 15:03:29 +02:00
AttributeSet Attrs = getAttributes(Index);
AttributeSet NewAttrs = Attrs.removeAttributes(C, AttrsToRemove);
// If nothing was removed, return the original list.
if (Attrs == NewAttrs)
return *this;
[NFC] Rename attribute methods that work with indexes This is part one of a couple of patches to fully rename these methods. I've made the mistake of assuming that these indexes are for parameters multiple times, but actually they're based off of a weird indexing scheme AttributeList::AttrIndex where 0 is the return value and ~0 is the function. Hopefully renaming these methods will make this clearer. Ideally users should use more specific methods like AttributeList::getFnAttr(). This patch simply adds the name that we want in the end. This is so the removal of the methods with the original names happens in a separate change to make it easier for downstream users. This touches all relevant methods in AttributeList, CallBase, and Function. Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D108788
2021-08-20 10:49:36 -07:00
return setAttributesAtIndex(C, Index, NewAttrs);
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-06 23:19:43 +00:00
}
[NFC] Rename attribute methods that work with indexes This is part one of a couple of patches to fully rename these methods. I've made the mistake of assuming that these indexes are for parameters multiple times, but actually they're based off of a weird indexing scheme AttributeList::AttrIndex where 0 is the return value and ~0 is the function. Hopefully renaming these methods will make this clearer. Ideally users should use more specific methods like AttributeList::getFnAttr(). This patch simply adds the name that we want in the end. This is so the removal of the methods with the original names happens in a separate change to make it easier for downstream users. This touches all relevant methods in AttributeList, CallBase, and Function. Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D108788
2021-08-20 10:49:36 -07:00
AttributeList
AttributeList::removeAttributesAtIndex(LLVMContext &C,
unsigned WithoutIndex) 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-10 23:31:05 +00:00
if (!pImpl)
[IR] Fix some Clang-tidy modernize-use-auto warnings; other minor fixes (NFC). llvm-svn: 328850
2018-03-30 00:47:31 +00: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-23 17:01:48 +00: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-10 23:31:05 +00:00
}
[NFC] Replace some attribute methods that use confusing indexes
2021-08-19 14:02:11 -07:00
AttributeList AttributeList::addDereferenceableRetAttr(LLVMContext &C,
uint64_t Bytes) const {
Use a sorted array instead of a map to store AttrBuilder string attributes Using and std::map<SmallString, SmallString> for target dependent attributes is inefficient: it makes its constructor slightly heavier, and involves extra allocation for each new string attribute. Storing the attribute key/value as strings implies extra allocation/copy step. Use a sorted vector instead. Given the low number of attributes generally involved, this is cheaper, as showcased by https://llvm-compile-time-tracker.com/compare.php?from=5de322295f4ade692dc4f1823ae4450ad3c48af2&to=05bc480bf641a9e3b466619af43a2d123ee3f71d&stat=instructions Differential Revision: https://reviews.llvm.org/D116599
2022-01-03 13:32:19 -05:00
AttrBuilder B(C);
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-14 19:37:54 +00:00
B.addDereferenceableAttr(Bytes);
[NFC] Replace some attribute methods that use confusing indexes
2021-08-19 14:02:11 -07:00
return addRetAttributes(C, B);
}
AttributeList AttributeList::addDereferenceableParamAttr(LLVMContext &C,
unsigned Index,
uint64_t Bytes) const {
Use a sorted array instead of a map to store AttrBuilder string attributes Using and std::map<SmallString, SmallString> for target dependent attributes is inefficient: it makes its constructor slightly heavier, and involves extra allocation for each new string attribute. Storing the attribute key/value as strings implies extra allocation/copy step. Use a sorted vector instead. Given the low number of attributes generally involved, this is cheaper, as showcased by https://llvm-compile-time-tracker.com/compare.php?from=5de322295f4ade692dc4f1823ae4450ad3c48af2&to=05bc480bf641a9e3b466619af43a2d123ee3f71d&stat=instructions Differential Revision: https://reviews.llvm.org/D116599
2022-01-03 13:32:19 -05:00
AttrBuilder B(C);
[NFC] Replace some attribute methods that use confusing indexes
2021-08-19 14:02:11 -07:00
B.addDereferenceableAttr(Bytes);
return addParamAttributes(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-14 19:37:54 +00: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-21 16:57:19 +00:00
AttributeList
[NFC] Cleanup/remove some AttributeList setter methods
2021-08-20 10:28:32 -07:00
AttributeList::addDereferenceableOrNullParamAttr(LLVMContext &C, unsigned Index,
uint64_t Bytes) const {
Use a sorted array instead of a map to store AttrBuilder string attributes Using and std::map<SmallString, SmallString> for target dependent attributes is inefficient: it makes its constructor slightly heavier, and involves extra allocation for each new string attribute. Storing the attribute key/value as strings implies extra allocation/copy step. Use a sorted vector instead. Given the low number of attributes generally involved, this is cheaper, as showcased by https://llvm-compile-time-tracker.com/compare.php?from=5de322295f4ade692dc4f1823ae4450ad3c48af2&to=05bc480bf641a9e3b466619af43a2d123ee3f71d&stat=instructions Differential Revision: https://reviews.llvm.org/D116599
2022-01-03 13:32:19 -05:00
AttrBuilder B(C);
[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-16 20:29:50 +00:00
B.addDereferenceableOrNullAttr(Bytes);
[NFC] Cleanup/remove some AttributeList setter methods
2021-08-20 10:28:32 -07:00
return addParamAttributes(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-16 20:29:50 +00: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-21 16:57:19 +00:00
AttributeList
[NFC] Cleanup/remove some AttributeList setter methods
2021-08-20 10:28:32 -07:00
AttributeList::addAllocSizeParamAttr(LLVMContext &C, unsigned Index,
unsigned ElemSizeArg,
const Optional<unsigned> &NumElemsArg) {
Use a sorted array instead of a map to store AttrBuilder string attributes Using and std::map<SmallString, SmallString> for target dependent attributes is inefficient: it makes its constructor slightly heavier, and involves extra allocation for each new string attribute. Storing the attribute key/value as strings implies extra allocation/copy step. Use a sorted vector instead. Given the low number of attributes generally involved, this is cheaper, as showcased by https://llvm-compile-time-tracker.com/compare.php?from=5de322295f4ade692dc4f1823ae4450ad3c48af2&to=05bc480bf641a9e3b466619af43a2d123ee3f71d&stat=instructions Differential Revision: https://reviews.llvm.org/D116599
2022-01-03 13:32:19 -05:00
AttrBuilder B(C);
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 01:05:35 +00:00
B.addAllocSizeAttr(ElemSizeArg, NumElemsArg);
[NFC] Cleanup/remove some AttributeList setter methods
2021-08-20 10:28:32 -07:00
return addParamAttributes(C, Index, B);
[IR] Add vscale_range IR function attribute This attribute represents the minimum and maximum values vscale can take. For now this attribute is not hooked up to anything during codegen, this will be added in the future when such codegen is considered stable. Additionally hook up the -msve-vector-bits=<x> clang option to emit this attribute. Differential Revision: https://reviews.llvm.org/D98030
2021-03-03 13:53:30 +00:00
}
Reorder some functions and add comments. No functionality change. llvm-svn: 173733
2013-01-29 00:34:06 +00: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-21 16:57:19 +00:00
// AttributeList Accessor Methods
Reorder some functions and add comments. No functionality change. llvm-svn: 173733
2013-01-29 00:34:06 +00:00
//===----------------------------------------------------------------------===//
[NFC] Rename AttributeList::getParam/Ret/FnAttributes() -> get*Attributes() This is more consistent with similar methods.
2021-08-13 11:16:52 -07:00
AttributeSet AttributeList::getParamAttrs(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-03 18:17:31 +00:00
return getAttributes(ArgNo + FirstArgIndex);
Reorder some functions and add comments. No functionality change. llvm-svn: 173733
2013-01-29 00:34:06 +00:00
}
[NFC] Rename AttributeList::getParam/Ret/FnAttributes() -> get*Attributes() This is more consistent with similar methods.
2021-08-13 11:16:52 -07:00
AttributeSet AttributeList::getRetAttrs() 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-10 23:31:05 +00:00
return getAttributes(ReturnIndex);
Reorder some functions and add comments. No functionality change. llvm-svn: 173733
2013-01-29 00:34:06 +00:00
}
[NFC] Rename AttributeList::getParam/Ret/FnAttributes() -> get*Attributes() This is more consistent with similar methods.
2021-08-13 11:16:52 -07:00
AttributeSet AttributeList::getFnAttrs() 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-10 23:31:05 +00:00
return getAttributes(FunctionIndex);
Reorder some functions and add comments. No functionality change. llvm-svn: 173733
2013-01-29 00:34:06 +00:00
}
[NFC] Rename attribute methods that work with indexes This is part one of a couple of patches to fully rename these methods. I've made the mistake of assuming that these indexes are for parameters multiple times, but actually they're based off of a weird indexing scheme AttributeList::AttrIndex where 0 is the return value and ~0 is the function. Hopefully renaming these methods will make this clearer. Ideally users should use more specific methods like AttributeList::getFnAttr(). This patch simply adds the name that we want in the end. This is so the removal of the methods with the original names happens in a separate change to make it easier for downstream users. This touches all relevant methods in AttributeList, CallBase, and Function. Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D108788
2021-08-20 10:49:36 -07:00
bool AttributeList::hasAttributeAtIndex(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 00:38:00 +00:00
return getAttributes(Index).hasAttribute(Kind);
Reorder some functions and add comments. No functionality change. llvm-svn: 173733
2013-01-29 00:34:06 +00:00
}
[NFC] Rename attribute methods that work with indexes This is part one of a couple of patches to fully rename these methods. I've made the mistake of assuming that these indexes are for parameters multiple times, but actually they're based off of a weird indexing scheme AttributeList::AttrIndex where 0 is the return value and ~0 is the function. Hopefully renaming these methods will make this clearer. Ideally users should use more specific methods like AttributeList::getFnAttr(). This patch simply adds the name that we want in the end. This is so the removal of the methods with the original names happens in a separate change to make it easier for downstream users. This touches all relevant methods in AttributeList, CallBase, and Function. Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D108788
2021-08-20 10:49:36 -07:00
bool AttributeList::hasAttributeAtIndex(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 00:38:00 +00:00
return getAttributes(Index).hasAttribute(Kind);
Add some accessor and query methods for retrieving Attribute objects and such. llvm-svn: 175046
2013-02-13 08:42:21 +00:00
}
[NFC] Rename attribute methods that work with indexes This is part one of a couple of patches to fully rename these methods. I've made the mistake of assuming that these indexes are for parameters multiple times, but actually they're based off of a weird indexing scheme AttributeList::AttrIndex where 0 is the return value and ~0 is the function. Hopefully renaming these methods will make this clearer. Ideally users should use more specific methods like AttributeList::getFnAttr(). This patch simply adds the name that we want in the end. This is so the removal of the methods with the original names happens in a separate change to make it easier for downstream users. This touches all relevant methods in AttributeList, CallBase, and Function. Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D108788
2021-08-20 10:49:36 -07:00
bool AttributeList::hasAttributesAtIndex(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 00:38:00 +00:00
return getAttributes(Index).hasAttributes();
Reorder some functions and add comments. No functionality change. llvm-svn: 173733
2013-01-29 00:34:06 +00:00
}
[NFC] Rename AttributeList::hasFnAttribute() -> hasFnAttr() This is more consistent with similar methods.
2021-08-13 11:09:18 -07:00
bool AttributeList::hasFnAttr(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-29 22:25:19 +00:00
return pImpl && pImpl->hasFnAttribute(Kind);
}
[NFC] Rename AttributeList::hasFnAttribute() -> hasFnAttr() This is more consistent with similar methods.
2021-08-13 11:09:18 -07:00
bool AttributeList::hasFnAttr(StringRef Kind) const {
[NFC] Rename attribute methods that work with indexes This is part one of a couple of patches to fully rename these methods. I've made the mistake of assuming that these indexes are for parameters multiple times, but actually they're based off of a weird indexing scheme AttributeList::AttrIndex where 0 is the return value and ~0 is the function. Hopefully renaming these methods will make this clearer. Ideally users should use more specific methods like AttributeList::getFnAttr(). This patch simply adds the name that we want in the end. This is so the removal of the methods with the original names happens in a separate change to make it easier for downstream users. This touches all relevant methods in AttributeList, CallBase, and Function. Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D108788
2021-08-20 10:49:36 -07:00
return hasAttributeAtIndex(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 04:50:38 +00: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-21 16:57:19 +00: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-14 22:49:57 +02:00
return pImpl && pImpl->hasAttrSomewhere(Attr, Index);
Reorder some functions and add comments. No functionality change. llvm-svn: 173733
2013-01-29 00:34:06 +00:00
}
[NFC] Rename attribute methods that work with indexes This is part one of a couple of patches to fully rename these methods. I've made the mistake of assuming that these indexes are for parameters multiple times, but actually they're based off of a weird indexing scheme AttributeList::AttrIndex where 0 is the return value and ~0 is the function. Hopefully renaming these methods will make this clearer. Ideally users should use more specific methods like AttributeList::getFnAttr(). This patch simply adds the name that we want in the end. This is so the removal of the methods with the original names happens in a separate change to make it easier for downstream users. This touches all relevant methods in AttributeList, CallBase, and Function. Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D108788
2021-08-20 10:49:36 -07:00
Attribute AttributeList::getAttributeAtIndex(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 00:38:00 +00:00
return getAttributes(Index).getAttribute(Kind);
Add some accessor and query methods for retrieving Attribute objects and such. llvm-svn: 175046
2013-02-13 08:42:21 +00:00
}
[NFC] Rename attribute methods that work with indexes This is part one of a couple of patches to fully rename these methods. I've made the mistake of assuming that these indexes are for parameters multiple times, but actually they're based off of a weird indexing scheme AttributeList::AttrIndex where 0 is the return value and ~0 is the function. Hopefully renaming these methods will make this clearer. Ideally users should use more specific methods like AttributeList::getFnAttr(). This patch simply adds the name that we want in the end. This is so the removal of the methods with the original names happens in a separate change to make it easier for downstream users. This touches all relevant methods in AttributeList, CallBase, and Function. Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D108788
2021-08-20 10:49:36 -07:00
Attribute AttributeList::getAttributeAtIndex(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 00:38:00 +00:00
return getAttributes(Index).getAttribute(Kind);
Add some accessor and query methods for retrieving Attribute objects and such. llvm-svn: 175046
2013-02-13 08:42:21 +00: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 09:51:06 +00: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-28 20:34:27 +00: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 09:51:06 +00: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-03 18:17:31 +00:00
return getAttributes(ArgNo + FirstArgIndex).getAlignment();
Reorder some functions and add comments. No functionality change. llvm-svn: 173733
2013-01-29 00:34:06 +00:00
}
[clang][AArch64] Correctly align HFA arguments when passed on the stack When we pass a AArch64 Homogeneous Floating-Point Aggregate (HFA) argument with increased alignment requirements, for example struct S { __attribute__ ((__aligned__(16))) double v[4]; }; Clang uses `[4 x double]` for the parameter, which is passed on the stack at alignment 8, whereas it should be at alignment 16, following Rule C.4 in AAPCS (https://github.com/ARM-software/abi-aa/blob/master/aapcs64/aapcs64.rst#642parameter-passing-rules) Currently we don't have a way to express in LLVM IR the alignment requirements of the function arguments. The align attribute is applicable to pointers only, and only for some special ways of passing arguments (e..g byval). When implementing AAPCS32/AAPCS64, clang resorts to dubious hacks of coercing to types, which naturally have the needed alignment. We don't have enough types to cover all the cases, though. This patch introduces a new use of the stackalign attribute to control stack slot alignment, when and if an argument is passed in memory. The attribute align is left as an optimizer hint - it still applies to pointer types only and pertains to the content of the pointer, whereas the alignment of the pointer itself is determined by the stackalign attribute. For byval arguments, the stackalign attribute assumes the role, previously perfomed by align, falling back to align if stackalign` is absent. On the clang side, when passing arguments using the "direct" style (cf. `ABIArgInfo::Kind`), now we can optionally specify an alignment, which is emitted as the new `stackalign` attribute. Patch by Momchil Velikov and Lucas Prates. Differential Revision: https://reviews.llvm.org/D98794
2021-04-15 19:58:54 +01:00
MaybeAlign AttributeList::getParamStackAlignment(unsigned ArgNo) const {
return getAttributes(ArgNo + FirstArgIndex).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-30 18:48:23 +00: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 09:33:55 -04: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-05 16:58:47 -04: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-16 12:32:36 -07:00
Type *AttributeList::getParamPreallocatedType(unsigned Index) const {
return getAttributes(Index + FirstArgIndex).getPreallocatedType();
}
Reapply "OpaquePtr: Turn inalloca into a type attribute" This reverts commit 07e46367baeca96d84b03fa215b41775f69d5989.
2021-03-29 08:42:23 -04:00
Type *AttributeList::getParamInAllocaType(unsigned Index) const {
return getAttributes(Index + FirstArgIndex).getInAllocaType();
}
[BPF] Use elementtype attribute for preserve.array/struct.index intrinsics Use the elementtype attribute introduced in D105407 for the llvm.preserve.array/struct.index intrinsics. It carries the element type of the GEP these intrinsics effectively encode. This patch: * Adds a verifier check that the attribute is required. * Adds it in the IRBuilder methods for these intrinsics. * Autoupgrades old bitcode without the attribute. * Updates the lowering code to use the attribute rather than the pointer element type. * Updates lots of tests to specify the attribute. * Adds -force-opaque-pointers to the intrinsic-array.ll test to demonstrate they work now. https://reviews.llvm.org/D106184
2021-07-16 20:26:40 +02:00
Type *AttributeList::getParamElementType(unsigned Index) const {
return getAttributes(Index + FirstArgIndex).getElementType();
}
[NFC] Cleanup AttributeList::getStackAlignment() So that we don't use a confusing index.
2021-08-19 14:20:59 -07:00
MaybeAlign AttributeList::getFnStackAlignment() const {
return getFnAttrs().getStackAlignment();
}
MaybeAlign AttributeList::getRetStackAlignment() const {
return getRetAttrs().getStackAlignment();
Reorder some functions and add comments. No functionality change. llvm-svn: 173733
2013-01-29 00:34:06 +00:00
}
[NFC] Replace some attribute methods that use confusing indexes
2021-08-19 14:02:11 -07:00
uint64_t AttributeList::getRetDereferenceableBytes() const {
return getRetAttrs().getDereferenceableBytes();
}
uint64_t AttributeList::getParamDereferenceableBytes(unsigned Index) const {
return getParamAttrs(Index).getDereferenceableBytes();
}
uint64_t AttributeList::getRetDereferenceableOrNullBytes() const {
return getRetAttrs().getDereferenceableOrNullBytes();
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 15:51:28 +00:00
}
[NFC] Replace some attribute methods that use confusing indexes
2021-08-19 14:02:11 -07:00
uint64_t
AttributeList::getParamDereferenceableOrNullBytes(unsigned Index) const {
return getParamAttrs(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-06 17:41:54 +00:00
}
Extend the `uwtable` attribute with unwind table kind We have the `clang -cc1` command-line option `-funwind-tables=1|2` and the codegen option `VALUE_CODEGENOPT(UnwindTables, 2, 0) ///< Unwind tables (1) or asynchronous unwind tables (2)`. However, this is encoded in LLVM IR by the presence or the absence of the `uwtable` attribute, i.e. we lose the information whether to generate want just some unwind tables or asynchronous unwind tables. Asynchronous unwind tables take more space in the runtime image, I'd estimate something like 80-90% more, as the difference is adding roughly the same number of CFI directives as for prologues, only a bit simpler (e.g. `.cfi_offset reg, off` vs. `.cfi_restore reg`). Or even more, if you consider tail duplication of epilogue blocks. Asynchronous unwind tables could also restrict code generation to having only a finite number of frame pointer adjustments (an example of *not* having a finite number of `SP` adjustments is on AArch64 when untagging the stack (MTE) in some cases the compiler can modify `SP` in a loop). Having the CFI precise up to an instruction generally also means one cannot bundle together CFI instructions once the prologue is done, they need to be interspersed with ordinary instructions, which means extra `DW_CFA_advance_loc` commands, further increasing the unwind tables size. That is to say, async unwind tables impose a non-negligible overhead, yet for the most common use cases (like C++ exceptions), they are not even needed. This patch extends the `uwtable` attribute with an optional value: - `uwtable` (default to `async`) - `uwtable(sync)`, synchronous unwind tables - `uwtable(async)`, asynchronous (instruction precise) unwind tables Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D114543
2022-02-14 13:41:34 +00:00
UWTableKind AttributeList::getUWTableKind() const {
return getFnAttrs().getUWTableKind();
}
attributes: introduce allockind attr for describing allocator fn behavior I chose to encode the allockind information in a string constant because otherwise we would get a bit of an explosion of keywords to deal with the possible permutations of allocation function types. I'm not sure that CodeGen.h is the correct place for this enum, but it seemed to kind of match the UWTableKind enum so I put it in the same place. Constructive suggestions on a better location most certainly encouraged. Differential Revision: https://reviews.llvm.org/D123088
2022-03-29 11:14:07 -04:00
AllocFnKind AttributeList::getAllocKind() const {
return getFnAttrs().getAllocKind();
}
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-21 16:57:19 +00: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 00:38:00 +00:00
return getAttributes(Index).getAsString(InAttrGrp);
Reorder some functions and add comments. No functionality change. llvm-svn: 173733
2013-01-29 00:34:06 +00: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 00:38:00 +00: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-23 17:01:48 +00: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 00:47:31 +00: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-23 17:01:48 +00:00
return pImpl->begin()[Index];
Reorder some functions and add comments. No functionality change. llvm-svn: 173733
2013-01-29 00:34:06 +00:00
}
Verify the LLVMContext that an Attribute belongs to. Attributes don't know their parent Context, adding this would make Attribute larger. Instead, we add hasParentContext that answers whether this Attribute belongs to a particular LLVMContext by checking for itself inside the context's FoldingSet. Same with AttributeSet and AttributeList. The Verifier checks them with the Module context. Differential Revision: https://reviews.llvm.org/D99362
2021-03-24 16:13:29 -07:00
bool AttributeList::hasParentContext(LLVMContext &C) const {
assert(!isEmpty() && "an empty attribute list has no parent context");
FoldingSetNodeID ID;
pImpl->Profile(ID);
void *Unused;
return C.pImpl->AttrsLists.FindNodeOrInsertPos(ID, Unused) == pImpl;
}
[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-23 17:01:48 +00: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-01-31 23:53:05 +00: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-23 17:01:48 +00: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-01-31 23:53:05 +00:00
}
Reorder some functions and add comments. No functionality change. llvm-svn: 173733
2013-01-29 00:34:06 +00: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-21 16:57:19 +00:00
// AttributeList Introspection Methods
Reorder some functions and add comments. No functionality change. llvm-svn: 173733
2013-01-29 00:34:06 +00: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-23 17:01:48 +00: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 00:34:06 +00:00
}
Verify the LLVMContext that an Attribute belongs to. Attributes don't know their parent Context, adding this would make Attribute larger. Instead, we add hasParentContext that answers whether this Attribute belongs to a particular LLVMContext by checking for itself inside the context's FoldingSet. Same with AttributeSet and AttributeList. The Verifier checks them with the Module context. Differential Revision: https://reviews.llvm.org/D99362
2021-03-24 16:13:29 -07:00
void AttributeList::print(raw_ostream &O) const {
Improve error messages for attributes in the wrong context. verifyFunctionAttrs has a comment that the value V is printed in error messages. The recently added errors for attributes didn't print V. Make them print V. Change the stringification of AttributeList. Firstly they started with 'PAL[' which stood for ParamAttrsList. Change that to 'AttributeList[' matching its current name AttributeList. Print out semantic meaning of the index instead of the raw index value (i.e. 'return', 'function' or 'arg(n)'). Differential revision: https://reviews.llvm.org/D101484
2021-04-28 13:15:39 -07:00
O << "AttributeList[\n";
Reorder some functions and add comments. No functionality change. llvm-svn: 173733
2013-01-29 00:34:06 +00:00
[NFC][AttributeList] Replace index_begin/end with an iterator We expose the fact that we rely on unsigned wrapping to iterate through all indexes. This can be confusing. Rather, keeping it as an implementation detail through an iterator is less confusing and is less code. Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D110885
2021-09-30 13:57:55 -07:00
for (unsigned i : indexes()) {
Improve error messages for attributes in the wrong context. verifyFunctionAttrs has a comment that the value V is printed in error messages. The recently added errors for attributes didn't print V. Make them print V. Change the stringification of AttributeList. Firstly they started with 'PAL[' which stood for ParamAttrsList. Change that to 'AttributeList[' matching its current name AttributeList. Print out semantic meaning of the index instead of the raw index value (i.e. 'return', 'function' or 'arg(n)'). Differential revision: https://reviews.llvm.org/D101484
2021-04-28 13:15:39 -07:00
if (!getAttributes(i).hasAttributes())
continue;
O << " { ";
switch (i) {
case AttrIndex::ReturnIndex:
O << "return";
break;
case AttrIndex::FunctionIndex:
O << "function";
break;
default:
O << "arg(" << i - AttrIndex::FirstArgIndex << ")";
}
O << " => " << 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-12 17:45:29 +00:00
}
Cleanup whitespace. llvm-svn: 166013
2012-10-16 06:01:44 +00:00
Verify the LLVMContext that an Attribute belongs to. Attributes don't know their parent Context, adding this would make Attribute larger. Instead, we add hasParentContext that answers whether this Attribute belongs to a particular LLVMContext by checking for itself inside the context's FoldingSet. Same with AttributeSet and AttributeList. The Verifier checks them with the Module context. Differential Revision: https://reviews.llvm.org/D99362
2021-03-24 16:13:29 -07:00
O << "]\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-06 18:27:01 +00:00
}
Verify the LLVMContext that an Attribute belongs to. Attributes don't know their parent Context, adding this would make Attribute larger. Instead, we add hasParentContext that answers whether this Attribute belongs to a particular LLVMContext by checking for itself inside the context's FoldingSet. Same with AttributeSet and AttributeList. The Verifier checks them with the Module context. Differential Revision: https://reviews.llvm.org/D99362
2021-03-24 16:13:29 -07:00
#if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP)
LLVM_DUMP_METHOD void AttributeList::dump() const { print(dbgs()); }
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 02:02:38 +00: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-25 23:09:36 +00:00
Reorder some functions and add comments. No functionality change. llvm-svn: 173733
2013-01-29 00:34:06 +00:00
//===----------------------------------------------------------------------===//
// AttrBuilder Method Implementations
//===----------------------------------------------------------------------===//
Use a sorted array instead of a map to store AttrBuilder string attributes Using and std::map<SmallString, SmallString> for target dependent attributes is inefficient: it makes its constructor slightly heavier, and involves extra allocation for each new string attribute. Storing the attribute key/value as strings implies extra allocation/copy step. Use a sorted vector instead. Given the low number of attributes generally involved, this is cheaper, as showcased by https://llvm-compile-time-tracker.com/compare.php?from=5de322295f4ade692dc4f1823ae4450ad3c48af2&to=05bc480bf641a9e3b466619af43a2d123ee3f71d&stat=instructions Differential Revision: https://reviews.llvm.org/D116599
2022-01-03 13:32:19 -05:00
AttrBuilder::AttrBuilder(LLVMContext &Ctx, AttributeSet AS) : Ctx(Ctx) {
[AttrBuilder] Change storage to sorted vector (NFC) This follows up on the work in D116599, which changed AttrBuilder to store string attributes as SmallVector<Attribute>. This patch changes the implementation to store *all* attributes as a sorted vector. This both makes the implementation simpler and improves compile-time. We get a -0.5% geomean compile-time improvement on CTMark at O0. Differential Revision: https://reviews.llvm.org/D117558
2022-01-15 10:05:22 +01:00
append_range(Attrs, AS);
assert(is_sorted(Attrs) && "AttributeSet should be sorted");
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-10 23:31:05 +00:00
}
[AttrBuilder] Change storage to sorted vector (NFC) This follows up on the work in D116599, which changed AttrBuilder to store string attributes as SmallVector<Attribute>. This patch changes the implementation to store *all* attributes as a sorted vector. This both makes the implementation simpler and improves compile-time. We get a -0.5% geomean compile-time improvement on CTMark at O0. Differential Revision: https://reviews.llvm.org/D117558
2022-01-15 10:05:22 +01:00
void AttrBuilder::clear() { Attrs.clear(); }
Reorder some functions and add comments. No functionality change. llvm-svn: 173733
2013-01-29 00:34:06 +00:00
[AttrBuilder] Change storage to sorted vector (NFC) This follows up on the work in D116599, which changed AttrBuilder to store string attributes as SmallVector<Attribute>. This patch changes the implementation to store *all* attributes as a sorted vector. This both makes the implementation simpler and improves compile-time. We get a -0.5% geomean compile-time improvement on CTMark at O0. Differential Revision: https://reviews.llvm.org/D117558
2022-01-15 10:05:22 +01:00
/// Attribute comparator that only compares attribute keys. Enum attributes are
/// sorted before string attributes.
struct AttributeComparator {
Use a sorted array instead of a map to store AttrBuilder string attributes Using and std::map<SmallString, SmallString> for target dependent attributes is inefficient: it makes its constructor slightly heavier, and involves extra allocation for each new string attribute. Storing the attribute key/value as strings implies extra allocation/copy step. Use a sorted vector instead. Given the low number of attributes generally involved, this is cheaper, as showcased by https://llvm-compile-time-tracker.com/compare.php?from=5de322295f4ade692dc4f1823ae4450ad3c48af2&to=05bc480bf641a9e3b466619af43a2d123ee3f71d&stat=instructions Differential Revision: https://reviews.llvm.org/D116599
2022-01-03 13:32:19 -05:00
bool operator()(Attribute A0, Attribute A1) const {
[AttrBuilder] Change storage to sorted vector (NFC) This follows up on the work in D116599, which changed AttrBuilder to store string attributes as SmallVector<Attribute>. This patch changes the implementation to store *all* attributes as a sorted vector. This both makes the implementation simpler and improves compile-time. We get a -0.5% geomean compile-time improvement on CTMark at O0. Differential Revision: https://reviews.llvm.org/D117558
2022-01-15 10:05:22 +01:00
bool A0IsString = A0.isStringAttribute();
bool A1IsString = A1.isStringAttribute();
if (A0IsString) {
if (A1IsString)
return A0.getKindAsString() < A1.getKindAsString();
else
return false;
}
if (A1IsString)
return true;
return A0.getKindAsEnum() < A1.getKindAsEnum();
}
bool operator()(Attribute A0, Attribute::AttrKind Kind) const {
if (A0.isStringAttribute())
return false;
return A0.getKindAsEnum() < Kind;
Use a sorted array instead of a map to store AttrBuilder string attributes Using and std::map<SmallString, SmallString> for target dependent attributes is inefficient: it makes its constructor slightly heavier, and involves extra allocation for each new string attribute. Storing the attribute key/value as strings implies extra allocation/copy step. Use a sorted vector instead. Given the low number of attributes generally involved, this is cheaper, as showcased by https://llvm-compile-time-tracker.com/compare.php?from=5de322295f4ade692dc4f1823ae4450ad3c48af2&to=05bc480bf641a9e3b466619af43a2d123ee3f71d&stat=instructions Differential Revision: https://reviews.llvm.org/D116599
2022-01-03 13:32:19 -05:00
}
bool operator()(Attribute A0, StringRef Kind) const {
[AttrBuilder] Change storage to sorted vector (NFC) This follows up on the work in D116599, which changed AttrBuilder to store string attributes as SmallVector<Attribute>. This patch changes the implementation to store *all* attributes as a sorted vector. This both makes the implementation simpler and improves compile-time. We get a -0.5% geomean compile-time improvement on CTMark at O0. Differential Revision: https://reviews.llvm.org/D117558
2022-01-15 10:05:22 +01:00
if (A0.isStringAttribute())
return A0.getKindAsString() < Kind;
return true;
Use a sorted array instead of a map to store AttrBuilder string attributes Using and std::map<SmallString, SmallString> for target dependent attributes is inefficient: it makes its constructor slightly heavier, and involves extra allocation for each new string attribute. Storing the attribute key/value as strings implies extra allocation/copy step. Use a sorted vector instead. Given the low number of attributes generally involved, this is cheaper, as showcased by https://llvm-compile-time-tracker.com/compare.php?from=5de322295f4ade692dc4f1823ae4450ad3c48af2&to=05bc480bf641a9e3b466619af43a2d123ee3f71d&stat=instructions Differential Revision: https://reviews.llvm.org/D116599
2022-01-03 13:32:19 -05:00
}
};
[AttrBuilder] Change storage to sorted vector (NFC) This follows up on the work in D116599, which changed AttrBuilder to store string attributes as SmallVector<Attribute>. This patch changes the implementation to store *all* attributes as a sorted vector. This both makes the implementation simpler and improves compile-time. We get a -0.5% geomean compile-time improvement on CTMark at O0. Differential Revision: https://reviews.llvm.org/D117558
2022-01-15 10:05:22 +01:00
template <typename K>
static void addAttributeImpl(SmallVectorImpl<Attribute> &Attrs, K Kind,
Attribute Attr) {
auto It = lower_bound(Attrs, Kind, AttributeComparator());
if (It != Attrs.end() && It->hasAttribute(Kind))
std::swap(*It, Attr);
else
Attrs.insert(It, Attr);
}
Reorder some functions and add comments. No functionality change. llvm-svn: 173733
2013-01-29 00:34:06 +00:00
[AttrBuilder] Change storage to sorted vector (NFC) This follows up on the work in D116599, which changed AttrBuilder to store string attributes as SmallVector<Attribute>. This patch changes the implementation to store *all* attributes as a sorted vector. This both makes the implementation simpler and improves compile-time. We get a -0.5% geomean compile-time improvement on CTMark at O0. Differential Revision: https://reviews.llvm.org/D117558
2022-01-15 10:05:22 +01:00
AttrBuilder &AttrBuilder::addAttribute(Attribute Attr) {
if (Attr.isStringAttribute())
addAttributeImpl(Attrs, Attr.getKindAsString(), Attr);
else
addAttributeImpl(Attrs, Attr.getKindAsEnum(), Attr);
return *this;
}
Reapply "OpaquePtr: Turn inalloca into a type attribute" This reverts commit 07e46367baeca96d84b03fa215b41775f69d5989.
2021-03-29 08:42:23 -04:00
[AttrBuilder] Change storage to sorted vector (NFC) This follows up on the work in D116599, which changed AttrBuilder to store string attributes as SmallVector<Attribute>. This patch changes the implementation to store *all* attributes as a sorted vector. This both makes the implementation simpler and improves compile-time. We get a -0.5% geomean compile-time improvement on CTMark at O0. Differential Revision: https://reviews.llvm.org/D117558
2022-01-15 10:05:22 +01:00
AttrBuilder &AttrBuilder::addAttribute(Attribute::AttrKind Kind) {
addAttributeImpl(Attrs, Kind, Attribute::get(Ctx, Kind));
Reorder some functions and add comments. No functionality change. llvm-svn: 173733
2013-01-29 00:34:06 +00:00
return *this;
}
Add target-dependent versions of addAttribute/removeAttribute to AttrBuilder. llvm-svn: 174356
2013-02-05 08:09:32 +00:00
AttrBuilder &AttrBuilder::addAttribute(StringRef A, StringRef V) {
[AttrBuilder] Change storage to sorted vector (NFC) This follows up on the work in D116599, which changed AttrBuilder to store string attributes as SmallVector<Attribute>. This patch changes the implementation to store *all* attributes as a sorted vector. This both makes the implementation simpler and improves compile-time. We get a -0.5% geomean compile-time improvement on CTMark at O0. Differential Revision: https://reviews.llvm.org/D117558
2022-01-15 10:05:22 +01:00
addAttributeImpl(Attrs, A, Attribute::get(Ctx, A, V));
return *this;
Add target-dependent versions of addAttribute/removeAttribute to AttrBuilder. llvm-svn: 174356
2013-02-05 08:09:32 +00:00
}
s/AttrBuilder::addAttributes/AttrBuilder::addAttribute/g because that's more descriptive of what it actually is. llvm-svn: 174116
2013-01-31 23:38:01 +00: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 12:09:51 +00:00
assert((unsigned)Val < Attribute::EndAttrKinds && "Attribute out of range!");
[AttrBuilder] Change storage to sorted vector (NFC) This follows up on the work in D116599, which changed AttrBuilder to store string attributes as SmallVector<Attribute>. This patch changes the implementation to store *all* attributes as a sorted vector. This both makes the implementation simpler and improves compile-time. We get a -0.5% geomean compile-time improvement on CTMark at O0. Differential Revision: https://reviews.llvm.org/D117558
2022-01-15 10:05:22 +01:00
auto It = lower_bound(Attrs, Val, AttributeComparator());
if (It != Attrs.end() && It->hasAttribute(Val))
Attrs.erase(It);
s/AttrBuilder::addAttributes/AttrBuilder::addAttribute/g because that's more descriptive of what it actually is. llvm-svn: 174116
2013-01-31 23:38:01 +00:00
return *this;
}
Add target-dependent versions of addAttribute/removeAttribute to AttrBuilder. llvm-svn: 174356
2013-02-05 08:09:32 +00:00
AttrBuilder &AttrBuilder::removeAttribute(StringRef A) {
[AttrBuilder] Change storage to sorted vector (NFC) This follows up on the work in D116599, which changed AttrBuilder to store string attributes as SmallVector<Attribute>. This patch changes the implementation to store *all* attributes as a sorted vector. This both makes the implementation simpler and improves compile-time. We get a -0.5% geomean compile-time improvement on CTMark at O0. Differential Revision: https://reviews.llvm.org/D117558
2022-01-15 10:05:22 +01:00
auto It = lower_bound(Attrs, A, AttributeComparator());
if (It != Attrs.end() && It->hasAttribute(A))
Attrs.erase(It);
Add target-dependent versions of addAttribute/removeAttribute to AttrBuilder. llvm-svn: 174356
2013-02-05 08:09:32 +00:00
return *this;
}
[AttrBuilder] Make handling of int attribtues more generifc (NFC) This is basically the same change as 42cc7f3c524a0ede6b903486c588003fe12d9293 but for integer attributes. Rather than treating each attribute individually, handle them all the same way. The only thing that needs to be done per attribute is specify how get/add convert from/to the raw representation.
2021-10-03 22:23:05 +02:00
uint64_t AttrBuilder::getRawIntAttr(Attribute::AttrKind Kind) const {
[AttrBuilder] Change storage to sorted vector (NFC) This follows up on the work in D116599, which changed AttrBuilder to store string attributes as SmallVector<Attribute>. This patch changes the implementation to store *all* attributes as a sorted vector. This both makes the implementation simpler and improves compile-time. We get a -0.5% geomean compile-time improvement on CTMark at O0. Differential Revision: https://reviews.llvm.org/D117558
2022-01-15 10:05:22 +01:00
assert(Attribute::isIntAttrKind(Kind) && "Not an int attribute");
Attribute A = getAttribute(Kind);
return A.isValid() ? A.getValueAsInt() : 0;
[AttrBuilder] Make handling of int attribtues more generifc (NFC) This is basically the same change as 42cc7f3c524a0ede6b903486c588003fe12d9293 but for integer attributes. Rather than treating each attribute individually, handle them all the same way. The only thing that needs to be done per attribute is specify how get/add convert from/to the raw representation.
2021-10-03 22:23:05 +02:00
}
AttrBuilder &AttrBuilder::addRawIntAttr(Attribute::AttrKind Kind,
uint64_t Value) {
[AttrBuilder] Change storage to sorted vector (NFC) This follows up on the work in D116599, which changed AttrBuilder to store string attributes as SmallVector<Attribute>. This patch changes the implementation to store *all* attributes as a sorted vector. This both makes the implementation simpler and improves compile-time. We get a -0.5% geomean compile-time improvement on CTMark at O0. Differential Revision: https://reviews.llvm.org/D117558
2022-01-15 10:05:22 +01:00
return addAttribute(Attribute::get(Ctx, Kind, Value));
[AttrBuilder] Make handling of int attribtues more generifc (NFC) This is basically the same change as 42cc7f3c524a0ede6b903486c588003fe12d9293 but for integer attributes. Rather than treating each attribute individually, handle them all the same way. The only thing that needs to be done per attribute is specify how get/add convert from/to the raw representation.
2021-10-03 22:23:05 +02: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 01:05:35 +00:00
std::pair<unsigned, Optional<unsigned>> AttrBuilder::getAllocSizeArgs() const {
[AttrBuilder] Make handling of int attribtues more generifc (NFC) This is basically the same change as 42cc7f3c524a0ede6b903486c588003fe12d9293 but for integer attributes. Rather than treating each attribute individually, handle them all the same way. The only thing that needs to be done per attribute is specify how get/add convert from/to the raw representation.
2021-10-03 22:23:05 +02:00
return unpackAllocSizeArgs(getRawIntAttr(Attribute::AllocSize));
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 01:05:35 +00:00
}
[IR] Split vscale_range interface Interface is split from: std::pair<unsigned, unsigned> getVScaleRangeArgs() into separate functions for min/max: unsigned getVScaleRangeMin(); Optional<unsigned> getVScaleRangeMax(); Reviewed By: sdesmalen, paulwalker-arm Differential Revision: https://reviews.llvm.org/D114075
2021-12-07 09:53:16 +00:00
unsigned AttrBuilder::getVScaleRangeMin() const {
return unpackVScaleRangeArgs(getRawIntAttr(Attribute::VScaleRange)).first;
}
Optional<unsigned> AttrBuilder::getVScaleRangeMax() const {
return unpackVScaleRangeArgs(getRawIntAttr(Attribute::VScaleRange)).second;
[IR] Add vscale_range IR function attribute This attribute represents the minimum and maximum values vscale can take. For now this attribute is not hooked up to anything during codegen, this will be added in the future when such codegen is considered stable. Additionally hook up the -msve-vector-bits=<x> clang option to emit this attribute. Differential Revision: https://reviews.llvm.org/D98030
2021-03-03 13:53:30 +00: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 09:51:06 +00: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 09:16:33 +00:00
if (!Align)
return *this;
Reorder some functions and add comments. No functionality change. llvm-svn: 173733
2013-01-29 00:34:06 +00: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-23 22:50:06 +03:00
assert(*Align <= llvm::Value::MaximumAlignment && "Alignment too large.");
[AttrBuilder] Make handling of int attribtues more generifc (NFC) This is basically the same change as 42cc7f3c524a0ede6b903486c588003fe12d9293 but for integer attributes. Rather than treating each attribute individually, handle them all the same way. The only thing that needs to be done per attribute is specify how get/add convert from/to the raw representation.
2021-10-03 22:23:05 +02:00
return addRawIntAttr(Attribute::Alignment, Align->value());
Reorder some functions and add comments. No functionality change. llvm-svn: 173733
2013-01-29 00:34:06 +00: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 09:51:06 +00:00
AttrBuilder &AttrBuilder::addStackAlignmentAttr(MaybeAlign Align) {
Reorder some functions and add comments. No functionality change. llvm-svn: 173733
2013-01-29 00:34:06 +00: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 09:16:33 +00:00
if (!Align)
return *this;
Reorder some functions and add comments. No functionality change. llvm-svn: 173733
2013-01-29 00:34:06 +00: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 09:16:33 +00:00
assert(*Align <= 0x100 && "Alignment too large.");
[AttrBuilder] Make handling of int attribtues more generifc (NFC) This is basically the same change as 42cc7f3c524a0ede6b903486c588003fe12d9293 but for integer attributes. Rather than treating each attribute individually, handle them all the same way. The only thing that needs to be done per attribute is specify how get/add convert from/to the raw representation.
2021-10-03 22:23:05 +02:00
return addRawIntAttr(Attribute::StackAlignment, Align->value());
Reorder some functions and add comments. No functionality change. llvm-svn: 173733
2013-01-29 00:34:06 +00: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 15:51:28 +00:00
AttrBuilder &AttrBuilder::addDereferenceableAttr(uint64_t Bytes) {
if (Bytes == 0) return *this;
[AttrBuilder] Make handling of int attribtues more generifc (NFC) This is basically the same change as 42cc7f3c524a0ede6b903486c588003fe12d9293 but for integer attributes. Rather than treating each attribute individually, handle them all the same way. The only thing that needs to be done per attribute is specify how get/add convert from/to the raw representation.
2021-10-03 22:23:05 +02:00
return addRawIntAttr(Attribute::Dereferenceable, Bytes);
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 15:51:28 +00: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-16 20:29:50 +00:00
AttrBuilder &AttrBuilder::addDereferenceableOrNullAttr(uint64_t Bytes) {
if (Bytes == 0)
return *this;
[AttrBuilder] Make handling of int attribtues more generifc (NFC) This is basically the same change as 42cc7f3c524a0ede6b903486c588003fe12d9293 but for integer attributes. Rather than treating each attribute individually, handle them all the same way. The only thing that needs to be done per attribute is specify how get/add convert from/to the raw representation.
2021-10-03 22:23:05 +02:00
return addRawIntAttr(Attribute::DereferenceableOrNull, 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-16 20:29:50 +00: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 01:05:35 +00: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)");
[AttrBuilder] Make handling of int attribtues more generifc (NFC) This is basically the same change as 42cc7f3c524a0ede6b903486c588003fe12d9293 but for integer attributes. Rather than treating each attribute individually, handle them all the same way. The only thing that needs to be done per attribute is specify how get/add convert from/to the raw representation.
2021-10-03 22:23:05 +02:00
return addRawIntAttr(Attribute::AllocSize, RawArgs);
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 01:05:35 +00:00
}
[IR] Add vscale_range IR function attribute This attribute represents the minimum and maximum values vscale can take. For now this attribute is not hooked up to anything during codegen, this will be added in the future when such codegen is considered stable. Additionally hook up the -msve-vector-bits=<x> clang option to emit this attribute. Differential Revision: https://reviews.llvm.org/D98030
2021-03-03 13:53:30 +00:00
AttrBuilder &AttrBuilder::addVScaleRangeAttr(unsigned MinValue,
[IR] Split vscale_range interface Interface is split from: std::pair<unsigned, unsigned> getVScaleRangeArgs() into separate functions for min/max: unsigned getVScaleRangeMin(); Optional<unsigned> getVScaleRangeMax(); Reviewed By: sdesmalen, paulwalker-arm Differential Revision: https://reviews.llvm.org/D114075
2021-12-07 09:53:16 +00:00
Optional<unsigned> MaxValue) {
[IR] Add vscale_range IR function attribute This attribute represents the minimum and maximum values vscale can take. For now this attribute is not hooked up to anything during codegen, this will be added in the future when such codegen is considered stable. Additionally hook up the -msve-vector-bits=<x> clang option to emit this attribute. Differential Revision: https://reviews.llvm.org/D98030
2021-03-03 13:53:30 +00:00
return addVScaleRangeAttrFromRawRepr(packVScaleRangeArgs(MinValue, MaxValue));
}
AttrBuilder &AttrBuilder::addVScaleRangeAttrFromRawRepr(uint64_t RawArgs) {
// (0, 0) is not present hence ignore this case
if (RawArgs == 0)
return *this;
[AttrBuilder] Make handling of int attribtues more generifc (NFC) This is basically the same change as 42cc7f3c524a0ede6b903486c588003fe12d9293 but for integer attributes. Rather than treating each attribute individually, handle them all the same way. The only thing that needs to be done per attribute is specify how get/add convert from/to the raw representation.
2021-10-03 22:23:05 +02:00
return addRawIntAttr(Attribute::VScaleRange, RawArgs);
[IR] Add vscale_range IR function attribute This attribute represents the minimum and maximum values vscale can take. For now this attribute is not hooked up to anything during codegen, this will be added in the future when such codegen is considered stable. Additionally hook up the -msve-vector-bits=<x> clang option to emit this attribute. Differential Revision: https://reviews.llvm.org/D98030
2021-03-03 13:53:30 +00:00
}
Extend the `uwtable` attribute with unwind table kind We have the `clang -cc1` command-line option `-funwind-tables=1|2` and the codegen option `VALUE_CODEGENOPT(UnwindTables, 2, 0) ///< Unwind tables (1) or asynchronous unwind tables (2)`. However, this is encoded in LLVM IR by the presence or the absence of the `uwtable` attribute, i.e. we lose the information whether to generate want just some unwind tables or asynchronous unwind tables. Asynchronous unwind tables take more space in the runtime image, I'd estimate something like 80-90% more, as the difference is adding roughly the same number of CFI directives as for prologues, only a bit simpler (e.g. `.cfi_offset reg, off` vs. `.cfi_restore reg`). Or even more, if you consider tail duplication of epilogue blocks. Asynchronous unwind tables could also restrict code generation to having only a finite number of frame pointer adjustments (an example of *not* having a finite number of `SP` adjustments is on AArch64 when untagging the stack (MTE) in some cases the compiler can modify `SP` in a loop). Having the CFI precise up to an instruction generally also means one cannot bundle together CFI instructions once the prologue is done, they need to be interspersed with ordinary instructions, which means extra `DW_CFA_advance_loc` commands, further increasing the unwind tables size. That is to say, async unwind tables impose a non-negligible overhead, yet for the most common use cases (like C++ exceptions), they are not even needed. This patch extends the `uwtable` attribute with an optional value: - `uwtable` (default to `async`) - `uwtable(sync)`, synchronous unwind tables - `uwtable(async)`, asynchronous (instruction precise) unwind tables Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D114543
2022-02-14 13:41:34 +00:00
AttrBuilder &AttrBuilder::addUWTableAttr(UWTableKind Kind) {
if (Kind == UWTableKind::None)
return *this;
return addRawIntAttr(Attribute::UWTable, uint64_t(Kind));
}
attributes: introduce allockind attr for describing allocator fn behavior I chose to encode the allockind information in a string constant because otherwise we would get a bit of an explosion of keywords to deal with the possible permutations of allocation function types. I'm not sure that CodeGen.h is the correct place for this enum, but it seemed to kind of match the UWTableKind enum so I put it in the same place. Constructive suggestions on a better location most certainly encouraged. Differential Revision: https://reviews.llvm.org/D123088
2022-03-29 11:14:07 -04:00
AttrBuilder &AttrBuilder::addAllocKindAttr(AllocFnKind Kind) {
return addRawIntAttr(Attribute::AllocKind, static_cast<uint64_t>(Kind));
}
[Attributes] Make type attribute handling more generic (NFCI) Followup to D105658 to make AttrBuilder automatically work with new type attributes. TableGen is tweaked to emit First/LastTypeAttr markers, based on which we can handle type attributes programmatically. Differential Revision: https://reviews.llvm.org/D105763
2021-07-10 18:36:00 +02:00
Type *AttrBuilder::getTypeAttr(Attribute::AttrKind Kind) const {
[AttrBuilder] Change storage to sorted vector (NFC) This follows up on the work in D116599, which changed AttrBuilder to store string attributes as SmallVector<Attribute>. This patch changes the implementation to store *all* attributes as a sorted vector. This both makes the implementation simpler and improves compile-time. We get a -0.5% geomean compile-time improvement on CTMark at O0. Differential Revision: https://reviews.llvm.org/D117558
2022-01-15 10:05:22 +01:00
assert(Attribute::isTypeAttrKind(Kind) && "Not a type attribute");
Attribute A = getAttribute(Kind);
return A.isValid() ? A.getValueAsType() : nullptr;
[Attributes] Make type attribute handling more generic (NFCI) Followup to D105658 to make AttrBuilder automatically work with new type attributes. TableGen is tweaked to emit First/LastTypeAttr markers, based on which we can handle type attributes programmatically. Differential Revision: https://reviews.llvm.org/D105763
2021-07-10 18:36:00 +02:00
}
[AttrBuilder] Make handling of type attributes more generic (NFCI) While working on the elementtype attribute, I felt that the type attribute handling in AttrBuilder is overly repetitive. This patch converts the separate Type* members into an std::array<Type*>, so that all type attribute kinds can be handled generically. There's more room for improvement here (especially when it comes to converting the AttrBuilder to an Attribute), but this seems like a good starting point. Differential Revision: https://reviews.llvm.org/D105658
2021-07-08 22:40:56 +02:00
AttrBuilder &AttrBuilder::addTypeAttr(Attribute::AttrKind Kind, Type *Ty) {
[AttrBuilder] Change storage to sorted vector (NFC) This follows up on the work in D116599, which changed AttrBuilder to store string attributes as SmallVector<Attribute>. This patch changes the implementation to store *all* attributes as a sorted vector. This both makes the implementation simpler and improves compile-time. We get a -0.5% geomean compile-time improvement on CTMark at O0. Differential Revision: https://reviews.llvm.org/D117558
2022-01-15 10:05:22 +01:00
return addAttribute(Attribute::get(Ctx, 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-30 18:48:23 +00:00
}
[AttrBuilder] Make handling of type attributes more generic (NFCI) While working on the elementtype attribute, I felt that the type attribute handling in AttrBuilder is overly repetitive. This patch converts the separate Type* members into an std::array<Type*>, so that all type attribute kinds can be handled generically. There's more room for improvement here (especially when it comes to converting the AttrBuilder to an Attribute), but this seems like a good starting point. Differential Revision: https://reviews.llvm.org/D105658
2021-07-08 22:40:56 +02:00
AttrBuilder &AttrBuilder::addByValAttr(Type *Ty) {
return addTypeAttr(Attribute::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 09:33:55 -04:00
AttrBuilder &AttrBuilder::addStructRetAttr(Type *Ty) {
[AttrBuilder] Make handling of type attributes more generic (NFCI) While working on the elementtype attribute, I felt that the type attribute handling in AttrBuilder is overly repetitive. This patch converts the separate Type* members into an std::array<Type*>, so that all type attribute kinds can be handled generically. There's more room for improvement here (especially when it comes to converting the AttrBuilder to an Attribute), but this seems like a good starting point. Differential Revision: https://reviews.llvm.org/D105658
2021-07-08 22:40:56 +02:00
return addTypeAttr(Attribute::StructRet, 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 09:33:55 -04:00
}
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-05 16:58:47 -04:00
AttrBuilder &AttrBuilder::addByRefAttr(Type *Ty) {
[AttrBuilder] Make handling of type attributes more generic (NFCI) While working on the elementtype attribute, I felt that the type attribute handling in AttrBuilder is overly repetitive. This patch converts the separate Type* members into an std::array<Type*>, so that all type attribute kinds can be handled generically. There's more room for improvement here (especially when it comes to converting the AttrBuilder to an Attribute), but this seems like a good starting point. Differential Revision: https://reviews.llvm.org/D105658
2021-07-08 22:40:56 +02:00
return addTypeAttr(Attribute::ByRef, 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-05 16:58:47 -04:00
}
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-14 14:16:53 -08:00
AttrBuilder &AttrBuilder::addPreallocatedAttr(Type *Ty) {
[AttrBuilder] Make handling of type attributes more generic (NFCI) While working on the elementtype attribute, I felt that the type attribute handling in AttrBuilder is overly repetitive. This patch converts the separate Type* members into an std::array<Type*>, so that all type attribute kinds can be handled generically. There's more room for improvement here (especially when it comes to converting the AttrBuilder to an Attribute), but this seems like a good starting point. Differential Revision: https://reviews.llvm.org/D105658
2021-07-08 22:40:56 +02:00
return addTypeAttr(Attribute::Preallocated, 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-14 14:16:53 -08:00
}
Reapply "OpaquePtr: Turn inalloca into a type attribute" This reverts commit 07e46367baeca96d84b03fa215b41775f69d5989.
2021-03-29 08:42:23 -04:00
AttrBuilder &AttrBuilder::addInAllocaAttr(Type *Ty) {
[AttrBuilder] Make handling of type attributes more generic (NFCI) While working on the elementtype attribute, I felt that the type attribute handling in AttrBuilder is overly repetitive. This patch converts the separate Type* members into an std::array<Type*>, so that all type attribute kinds can be handled generically. There's more room for improvement here (especially when it comes to converting the AttrBuilder to an Attribute), but this seems like a good starting point. Differential Revision: https://reviews.llvm.org/D105658
2021-07-08 22:40:56 +02:00
return addTypeAttr(Attribute::InAlloca, Ty);
Reapply "OpaquePtr: Turn inalloca into a type attribute" This reverts commit 07e46367baeca96d84b03fa215b41775f69d5989.
2021-03-29 08:42:23 -04:00
}
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 01:16:00 +00:00
AttrBuilder &AttrBuilder::merge(const AttrBuilder &B) {
[AttrBuilder] Change storage to sorted vector (NFC) This follows up on the work in D116599, which changed AttrBuilder to store string attributes as SmallVector<Attribute>. This patch changes the implementation to store *all* attributes as a sorted vector. This both makes the implementation simpler and improves compile-time. We get a -0.5% geomean compile-time improvement on CTMark at O0. Differential Revision: https://reviews.llvm.org/D117558
2022-01-15 10:05:22 +01:00
// TODO: Could make this O(n) as we're merging two sorted lists.
for (const auto &I : B.attrs())
Use a sorted array instead of a map to store AttrBuilder string attributes Using and std::map<SmallString, SmallString> for target dependent attributes is inefficient: it makes its constructor slightly heavier, and involves extra allocation for each new string attribute. Storing the attribute key/value as strings implies extra allocation/copy step. Use a sorted vector instead. Given the low number of attributes generally involved, this is cheaper, as showcased by https://llvm-compile-time-tracker.com/compare.php?from=5de322295f4ade692dc4f1823ae4450ad3c48af2&to=05bc480bf641a9e3b466619af43a2d123ee3f71d&stat=instructions Differential Revision: https://reviews.llvm.org/D116599
2022-01-03 13:32:19 -05:00
addAttribute(I);
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 01:16:00 +00:00
return *this;
}
Introduce the AttributeMask class This class is solely used as a lightweight and clean way to build a set of attributes to be removed from an AttrBuilder. Previously AttrBuilder was used both for building and removing, which introduced odd situation like creation of Attribute with dummy value because the only relevant part was the attribute kind. Differential Revision: https://reviews.llvm.org/D116110
2022-01-04 09:44:47 +01:00
AttrBuilder &AttrBuilder::remove(const AttributeMask &AM) {
[AttrBuilder] Change storage to sorted vector (NFC) This follows up on the work in D116599, which changed AttrBuilder to store string attributes as SmallVector<Attribute>. This patch changes the implementation to store *all* attributes as a sorted vector. This both makes the implementation simpler and improves compile-time. We get a -0.5% geomean compile-time improvement on CTMark at O0. Differential Revision: https://reviews.llvm.org/D117558
2022-01-15 10:05:22 +01:00
erase_if(Attrs, [&](Attribute A) { return AM.contains(A); });
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-06 23:19:43 +00:00
return *this;
}
Introduce the AttributeMask class This class is solely used as a lightweight and clean way to build a set of attributes to be removed from an AttrBuilder. Previously AttrBuilder was used both for building and removing, which introduced odd situation like creation of Attribute with dummy value because the only relevant part was the attribute kind. Differential Revision: https://reviews.llvm.org/D116110
2022-01-04 09:44:47 +01:00
bool AttrBuilder::overlaps(const AttributeMask &AM) const {
[AttrBuilder] Change storage to sorted vector (NFC) This follows up on the work in D116599, which changed AttrBuilder to store string attributes as SmallVector<Attribute>. This patch changes the implementation to store *all* attributes as a sorted vector. This both makes the implementation simpler and improves compile-time. We get a -0.5% geomean compile-time improvement on CTMark at O0. Differential Revision: https://reviews.llvm.org/D117558
2022-01-15 10:05:22 +01:00
return any_of(Attrs, [&](Attribute A) { return AM.contains(A); });
}
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-06 23:19:43 +00:00
[AttrBuilder] Change storage to sorted vector (NFC) This follows up on the work in D116599, which changed AttrBuilder to store string attributes as SmallVector<Attribute>. This patch changes the implementation to store *all* attributes as a sorted vector. This both makes the implementation simpler and improves compile-time. We get a -0.5% geomean compile-time improvement on CTMark at O0. Differential Revision: https://reviews.llvm.org/D117558
2022-01-15 10:05:22 +01:00
Attribute AttrBuilder::getAttribute(Attribute::AttrKind A) const {
assert((unsigned)A < Attribute::EndAttrKinds && "Attribute out of range!");
auto It = lower_bound(Attrs, A, AttributeComparator());
if (It != Attrs.end() && It->hasAttribute(A))
return *It;
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-06 23:19:43 +00:00
}
[AttrBuilder] Add string attribute getter (NFC) This avoids the need to scan through td_attrs() in AutoUpgrade, decoupling it from AttrBuilder implementation details.
2022-01-18 12:12:22 +01:00
Attribute AttrBuilder::getAttribute(StringRef A) const {
[AttrBuilder] Change storage to sorted vector (NFC) This follows up on the work in D116599, which changed AttrBuilder to store string attributes as SmallVector<Attribute>. This patch changes the implementation to store *all* attributes as a sorted vector. This both makes the implementation simpler and improves compile-time. We get a -0.5% geomean compile-time improvement on CTMark at O0. Differential Revision: https://reviews.llvm.org/D117558
2022-01-15 10:05:22 +01:00
auto It = lower_bound(Attrs, A, AttributeComparator());
if (It != Attrs.end() && It->hasAttribute(A))
[AttrBuilder] Add string attribute getter (NFC) This avoids the need to scan through td_attrs() in AutoUpgrade, decoupling it from AttrBuilder implementation details.
2022-01-18 12:12:22 +01:00
return *It;
return {};
}
[AttrBuilder] Change storage to sorted vector (NFC) This follows up on the work in D116599, which changed AttrBuilder to store string attributes as SmallVector<Attribute>. This patch changes the implementation to store *all* attributes as a sorted vector. This both makes the implementation simpler and improves compile-time. We get a -0.5% geomean compile-time improvement on CTMark at O0. Differential Revision: https://reviews.llvm.org/D117558
2022-01-15 10:05:22 +01:00
bool AttrBuilder::contains(Attribute::AttrKind A) const {
[AttrBuilder] Add string attribute getter (NFC) This avoids the need to scan through td_attrs() in AutoUpgrade, decoupling it from AttrBuilder implementation details.
2022-01-18 12:12:22 +01:00
return getAttribute(A).isValid();
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 01:33:42 +00:00
}
[AttrBuilder] Change storage to sorted vector (NFC) This follows up on the work in D116599, which changed AttrBuilder to store string attributes as SmallVector<Attribute>. This patch changes the implementation to store *all* attributes as a sorted vector. This both makes the implementation simpler and improves compile-time. We get a -0.5% geomean compile-time improvement on CTMark at O0. Differential Revision: https://reviews.llvm.org/D117558
2022-01-15 10:05:22 +01:00
bool AttrBuilder::contains(StringRef A) const {
return getAttribute(A).isValid();
Reorder some functions and add comments. No functionality change. llvm-svn: 173733
2013-01-29 00:34:06 +00:00
}
bool AttrBuilder::hasAlignmentAttr() const {
[AttrBuilder] Make handling of int attribtues more generifc (NFC) This is basically the same change as 42cc7f3c524a0ede6b903486c588003fe12d9293 but for integer attributes. Rather than treating each attribute individually, handle them all the same way. The only thing that needs to be done per attribute is specify how get/add convert from/to the raw representation.
2021-10-03 22:23:05 +02:00
return getRawIntAttr(Attribute::Alignment) != 0;
Reorder some functions and add comments. No functionality change. llvm-svn: 173733
2013-01-29 00:34:06 +00:00
}
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 10:41:35 +00:00
bool AttrBuilder::operator==(const AttrBuilder &B) const {
[AttrBuilder] Change storage to sorted vector (NFC) This follows up on the work in D116599, which changed AttrBuilder to store string attributes as SmallVector<Attribute>. This patch changes the implementation to store *all* attributes as a sorted vector. This both makes the implementation simpler and improves compile-time. We get a -0.5% geomean compile-time improvement on CTMark at O0. Differential Revision: https://reviews.llvm.org/D117558
2022-01-15 10:05:22 +01:00
return Attrs == B.Attrs;
Reorder some functions and add comments. No functionality change. llvm-svn: 173733
2013-01-29 00:34:06 +00: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-25 23:09:36 +00: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 15:54:18 +00:00
/// Which attributes cannot be applied to a type.
[InstCombineCalls] Optimize call of bitcast even w/ parameter attributes Before we gave up if a call through bitcast had parameter attributes. Interestingly, we allowed attributes for the return value already. We now handle both the same way, namely, we drop the ones that are incompatible with the new type and keep the rest. This cannot cause "more UB" than initially present. Differential Revision: https://reviews.llvm.org/D119967
2022-02-14 17:12:34 -06:00
AttributeMask AttributeFuncs::typeIncompatible(Type *Ty,
AttributeSafetyKind ASK) {
Introduce the AttributeMask class This class is solely used as a lightweight and clean way to build a set of attributes to be removed from an AttrBuilder. Previously AttrBuilder was used both for building and removing, which introduced odd situation like creation of Attribute with dummy value because the only relevant part was the attribute kind. Differential Revision: https://reviews.llvm.org/D116110
2022-01-04 09:44:47 +01:00
AttributeMask 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-25 23:09:36 +00:00
[InstCombineCalls] Optimize call of bitcast even w/ parameter attributes Before we gave up if a call through bitcast had parameter attributes. Interestingly, we allowed attributes for the return value already. We now handle both the same way, namely, we drop the ones that are incompatible with the new type and keep the rest. This cannot cause "more UB" than initially present. Differential Revision: https://reviews.llvm.org/D119967
2022-02-14 17:12:34 -06:00
if (!Ty->isIntegerTy()) {
[IR] Allow the 'align' param attr on vectors of pointers This patch extends the available uses of the 'align' parameter attribute to include vectors of pointers. The attribute specifies pointer alignment element-wise. This change was previously requested and discussed in D87304. The vector predication (VP) intrinsics intend to use this for scatter and gather operations, as they lack the explicit alignment parameter that the masked versions use. Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D115161
2021-12-06 15:49:23 +00:00
// Attributes that only apply to integers.
[InstCombineCalls] Optimize call of bitcast even w/ parameter attributes Before we gave up if a call through bitcast had parameter attributes. Interestingly, we allowed attributes for the return value already. We now handle both the same way, namely, we drop the ones that are incompatible with the new type and keep the rest. This cannot cause "more UB" than initially present. Differential Revision: https://reviews.llvm.org/D119967
2022-02-14 17:12:34 -06:00
if (ASK & ASK_SAFE_TO_DROP)
Incompatible.addAttribute(Attribute::AllocAlign);
if (ASK & ASK_UNSAFE_TO_DROP)
Incompatible.addAttribute(Attribute::SExt).addAttribute(Attribute::ZExt);
}
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-25 23:09:36 +00:00
[InstCombineCalls] Optimize call of bitcast even w/ parameter attributes Before we gave up if a call through bitcast had parameter attributes. Interestingly, we allowed attributes for the return value already. We now handle both the same way, namely, we drop the ones that are incompatible with the new type and keep the rest. This cannot cause "more UB" than initially present. Differential Revision: https://reviews.llvm.org/D119967
2022-02-14 17:12:34 -06:00
if (!Ty->isPointerTy()) {
[IR] Allow the 'align' param attr on vectors of pointers This patch extends the available uses of the 'align' parameter attribute to include vectors of pointers. The attribute specifies pointer alignment element-wise. This change was previously requested and discussed in D87304. The vector predication (VP) intrinsics intend to use this for scatter and gather operations, as they lack the explicit alignment parameter that the masked versions use. Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D115161
2021-12-06 15:49:23 +00:00
// Attributes that only apply to pointers.
[InstCombineCalls] Optimize call of bitcast even w/ parameter attributes Before we gave up if a call through bitcast had parameter attributes. Interestingly, we allowed attributes for the return value already. We now handle both the same way, namely, we drop the ones that are incompatible with the new type and keep the rest. This cannot cause "more UB" than initially present. Differential Revision: https://reviews.llvm.org/D119967
2022-02-14 17:12:34 -06:00
if (ASK & ASK_SAFE_TO_DROP)
Incompatible.addAttribute(Attribute::NoAlias)
.addAttribute(Attribute::NoCapture)
.addAttribute(Attribute::NonNull)
.addAttribute(Attribute::ReadNone)
.addAttribute(Attribute::ReadOnly)
.addAttribute(Attribute::Dereferenceable)
.addAttribute(Attribute::DereferenceableOrNull);
if (ASK & ASK_UNSAFE_TO_DROP)
Incompatible.addAttribute(Attribute::Nest)
.addAttribute(Attribute::SwiftError)
.addAttribute(Attribute::Preallocated)
.addAttribute(Attribute::InAlloca)
.addAttribute(Attribute::ByVal)
.addAttribute(Attribute::StructRet)
.addAttribute(Attribute::ByRef)
Attributes: add a new `allocptr` attribute This continues the push away from hard-coded knowledge about functions towards attributes. We'll use this to annotate free(), realloc() and cousins and obviate the hard-coded list of free functions. Differential Revision: https://reviews.llvm.org/D123083
2022-02-24 10:40:20 -05:00
.addAttribute(Attribute::ElementType)
.addAttribute(Attribute::AllocatedPointer);
[InstCombineCalls] Optimize call of bitcast even w/ parameter attributes Before we gave up if a call through bitcast had parameter attributes. Interestingly, we allowed attributes for the return value already. We now handle both the same way, namely, we drop the ones that are incompatible with the new type and keep the rest. This cannot cause "more UB" than initially present. Differential Revision: https://reviews.llvm.org/D119967
2022-02-14 17:12:34 -06:00
}
[IR] Allow the 'align' param attr on vectors of pointers This patch extends the available uses of the 'align' parameter attribute to include vectors of pointers. The attribute specifies pointer alignment element-wise. This change was previously requested and discussed in D87304. The vector predication (VP) intrinsics intend to use this for scatter and gather operations, as they lack the explicit alignment parameter that the masked versions use. Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D115161
2021-12-06 15:49:23 +00:00
// Attributes that only apply to pointers or vectors of pointers.
[InstCombineCalls] Optimize call of bitcast even w/ parameter attributes Before we gave up if a call through bitcast had parameter attributes. Interestingly, we allowed attributes for the return value already. We now handle both the same way, namely, we drop the ones that are incompatible with the new type and keep the rest. This cannot cause "more UB" than initially present. Differential Revision: https://reviews.llvm.org/D119967
2022-02-14 17:12:34 -06:00
if (!Ty->isPtrOrPtrVectorTy()) {
if (ASK & ASK_SAFE_TO_DROP)
Incompatible.addAttribute(Attribute::Alignment);
}
[IR] Allow the 'align' param attr on vectors of pointers This patch extends the available uses of the 'align' parameter attribute to include vectors of pointers. The attribute specifies pointer alignment element-wise. This change was previously requested and discussed in D87304. The vector predication (VP) intrinsics intend to use this for scatter and gather operations, as they lack the explicit alignment parameter that the masked versions use. Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D115161
2021-12-06 15:49:23 +00: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 10:13:11 -05:00
// Some attributes can apply to all "values" but there are no `void` values.
[InstCombineCalls] Optimize call of bitcast even w/ parameter attributes Before we gave up if a call through bitcast had parameter attributes. Interestingly, we allowed attributes for the return value already. We now handle both the same way, namely, we drop the ones that are incompatible with the new type and keep the rest. This cannot cause "more UB" than initially present. Differential Revision: https://reviews.llvm.org/D119967
2022-02-14 17:12:34 -06:00
if (Ty->isVoidTy()) {
if (ASK & ASK_SAFE_TO_DROP)
Incompatible.addAttribute(Attribute::NoUndef);
}
[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 10:13:11 -05:00
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-06 23:19:56 +00: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-25 23:09:36 +00: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-22 23:57:37 +00:00
Introduce the AttributeMask class This class is solely used as a lightweight and clean way to build a set of attributes to be removed from an AttrBuilder. Previously AttrBuilder was used both for building and removing, which introduced odd situation like creation of Attribute with dummy value because the only relevant part was the attribute kind. Differential Revision: https://reviews.llvm.org/D116110
2022-01-04 09:44:47 +01:00
AttributeMask AttributeFuncs::getUBImplyingAttributes() {
AttributeMask AM;
AM.addAttribute(Attribute::NoUndef);
AM.addAttribute(Attribute::Dereferenceable);
AM.addAttribute(Attribute::DereferenceableOrNull);
return AM;
[Attributes] Clean up handling of UB implying attributes (NFC) Rather than adding methods for dropping these attributes in various places, add a function that returns an AttrBuilder with these attributes, which can then be used with existing methods for dropping attributes. This is with an eye on D104641, which also needs to drop them from returns, not just parameters. Also be more explicit about the semantics of the method in the documentation. Refer to UB rather than Undef, which is what this is actually about.
2021-07-25 18:21:13 +02: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-22 23:57:37 +00: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 15:54:18 +00: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-22 23:57:37 +00: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 15:54:18 +00: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-22 23:57:37 +00: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 15:54:18 +00: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-22 23:57:37 +00:00
/// calling function, then bump up the caller's stack protection level.
static void adjustCallerSSPLevel(Function &Caller, const Function &Callee) {
Don't override __attribute__((no_stack_protector)) by inlining (PR52886) Since 26c6a3e736d3, LLVM's inliner will "upgrade" the caller's stack protector attribute based on the callee. This lead to surprising results with Clang's no_stack_protector attribute added in 4fbf84c1732f (D46300). Consider the following code compiled with clang -fstack-protector-strong -Os (https://godbolt.org/z/7s3rW7a1q). extern void h(int* p); inline __attribute__((always_inline)) int g() { return 0; } int __attribute__((__no_stack_protector__)) f() { int a[1]; h(a); return g(); } LLVM will inline g() into f(), and f() would get a stack protector, against the users explicit wishes, potentially breaking the program e.g. if h() changes the value of the stack cookie. That's a miscompile. More recently, bc044a88ee3c (D91816) addressed this problem by preventing inlining when the stack protector is disabled in the caller and enabled in the callee or vice versa. However, the problem remained if the callee is marked always_inline as in the example above. This affected users, see e.g. http://crbug.com/1274129 and http://llvm.org/pr52886. One way to fix this would be to prevent inlining also in the always_inline case. Despite the name, always_inline does not guarantee inlining, so this would be legal but potentially surprising to users. However, I think the better fix is to not enable the stack protector in a caller based on the callee. The motivation for the old behaviour is unclear, it seems counter-intuitive, and causes real problems as we've seen. This commit implements that fix, which means in the example above, g() gets inlined into f() (also without always_inline), and f() is emitted without stack protector. I think that matches most developers' expectations, and that's also what GCC does. Another effect of this change is that a no_stack_protector function can now be inlined into a stack protected function, e.g. (https://godbolt.org/z/hafP6W856): extern void h(int* p); inline int __attribute__((__no_stack_protector__)) __attribute__((always_inline)) g() { return 0; } int f() { int a[1]; h(a); return g(); } I think that's fine. Such code would be unusual since no_stack_protector is normally applied to a program entry point which sets up the stack canary. And even if such code exists, inlining doesn't change the semantics: there is still no stack cookie setup/check around entry/exit of the g() code region, but there may be in the surrounding context, as there was before inlining. This also matches GCC. See also the discussion at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94722 Differential revision: https://reviews.llvm.org/D116589
2022-01-03 18:03:43 +01:00
// If the calling function has *no* stack protection level (e.g. it was built
// with Clang's -fno-stack-protector or no_stack_protector attribute), don't
// change it as that could change the program's semantics.
if (!Caller.hasStackProtectorFnAttr())
return;
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-22 23:57:37 +00: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-17 17:17:44 -08:00
// Having multiple SSP attributes doesn't actually hurt, but it adds useless
// clutter to the IR.
Introduce the AttributeMask class This class is solely used as a lightweight and clean way to build a set of attributes to be removed from an AttrBuilder. Previously AttrBuilder was used both for building and removing, which introduced odd situation like creation of Attribute with dummy value because the only relevant part was the attribute kind. Differential Revision: https://reviews.llvm.org/D116110
2022-01-04 09:44:47 +01:00
AttributeMask OldSSPAttr;
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-02 22:07:37 +00:00
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-22 23:57:37 +00: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-11 22:27:48 +00:00
if (Callee.hasFnAttribute(Attribute::StackProtectReq)) {
[NFC] Migrate some callers away from Function/AttributeLists methods that take an index These methods can be confusing.
2021-08-16 17:12:49 -07:00
Caller.removeFnAttrs(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-22 23:57:37 +00:00
Caller.addFnAttr(Attribute::StackProtectReq);
} else if (Callee.hasFnAttribute(Attribute::StackProtectStrong) &&
!Caller.hasFnAttribute(Attribute::StackProtectReq)) {
[NFC] Migrate some callers away from Function/AttributeLists methods that take an index These methods can be confusing.
2021-08-16 17:12:49 -07:00
Caller.removeFnAttrs(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-22 23:57:37 +00: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 15:54:18 +00: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-21 18:46:50 +00: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-22 23:22:36 +00: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 15:54:18 +00: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-22 23:22:36 +00: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-28 23:15:34 -07: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-22 23:22:36 +00: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-28 23:15:34 -07: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-22 23:22:36 +00: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-28 23:15:34 -07: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-22 23:22:36 +00: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-21 18:46:50 +00: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-24 18:49:00 +00: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 07:27:38 +00: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-24 18:49:00 +00: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-28 23:15:34 -07: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 07:27:38 +00: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-28 23:15:34 -07: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-24 18:49:00 +00: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 07:27:38 +00: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-24 18:49:00 +00: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 12:57:07 +02: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-30 19:33:53 +00: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 12:57:07 +02: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-30 19:33:53 +00: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 14:46:50 +01: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-22 23:57:37 +00: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 14:46:50 +01: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-22 23:57:37 +00: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 03:24:59 -05: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-22 23:57:37 +00: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 03:24:59 -05: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);
}
[ArgPromotion][Attributor] Update min-legal-vector-width when do promotion X86 codegen uses function attribute `min-legal-vector-width` to select the proper ABI. The intention of the attribute is to reflect user's requirement when they passing or returning vector arguments. So Clang front-end will iterate the vector arguments and set `min-legal-vector-width` to the width of the maximum for both caller and callee. It is assumed any middle end optimizations won't care of the attribute expect inlining and argument promotion. - For inlining, we will propagate the attribute of inlined functions because the inlining functions become the newer caller. - For argument promotion, we check the `min-legal-vector-width` of the caller and callee and refuse to promote when they don't match. The problem comes from the optimizations' combination, as shown by https://godbolt.org/z/zo3hba8xW. The caller `foo` has two callees `bar` and `baz`. When doing argument promotion, both `foo` and `bar` has the same `min-legal-vector-width`. So the argument was promoted to vector. Then the inlining inlines `baz` to `foo` and updates `min-legal-vector-width`, which results in ABI mismatch between `foo` and `bar`. This patch fixes the problem by expanding the concept of `min-legal-vector-width` to indicator of functions arguments. That says, any passes touch functions arguments have to set `min-legal-vector-width` to the value reflects the width of vector arguments. It makes sense to me because any arguments modifications are ABI related and should response for the ABI compatibility. Differential Revision: https://reviews.llvm.org/D123284
2022-05-02 13:29:34 +08:00
void AttributeFuncs::updateMinLegalVectorWidthAttr(Function &Fn,
uint64_t Width) {
Attribute Attr = Fn.getFnAttribute("min-legal-vector-width");
if (Attr.isValid()) {
uint64_t OldWidth;
Attr.getValueAsString().getAsInteger(0, OldWidth);
if (Width > OldWidth)
Fn.addFnAttr("min-legal-vector-width", llvm::utostr(Width));
}
}
Reference in New Issue Copy Permalink