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
There are many instruction ctors that call the setName method of the Value base class, which can throw a bad_alloc exception in OOM situations.
In such situations special User delete operators are called which are not implemented yet.
Example:
Lets look at the construction of a CallInst instruction during IR generation:
static CallInst *Create(FunctionType *Ty, Value *Func, ArrayRef<Value *> Args, .. ){
...
return new (TotalOps, DescriptorBytes) CallInst(Ty, Func, Args, Bundles, NameStr, InsertBefore);
}
CallInst::CalInst(Value* Func, ...) {
...
Op<-1>() = Func;
....
setName(name); // throws
...
}
Op<-1>() returns a reference to a Use object of the CallInst instruction and the operator= inserts this use object into the UseList of Func.
The same object is removed from that UseList by calling the User::operator delete If the CallInst object is deleted.
Since setName can throw a bad_alloc exception (if LLVM_ENABLE_EXCEPTIONS is switched on), the unwind chain runs into assertions ("Constructor throws?") in
special User::operator deletes operators:
operator delete(void* Usr, unsigned)
operator delete(void* Usr, unsigned, bool)
This situation can be fixed by simlpy calling the User::operator delete(void*) in these unimplemented methods.
To ensure that this additional call succeeds all information that is necessary to calculate the storage pointer from the Usr address
must be restored in the special case that a sublass has changed this information, e.g. GlobalVariable can change the NumberOfOperands.
Reviewd by: rnk
Differential Revision: https://reviews.llvm.org/D42731
llvm-svn: 326316
The style guide states that the explicit `inline`
should not be used with inline methods. classof is
very common inline method with a fair amount on
inconsistency:
$ git grep classof ./include | grep inline | wc -l
230
$ git grep classof ./include | grep -v inline | wc -l
257
I chose to target this method rather the larger change
since this method is easily cargo-culted (I did it at
least once). I considered doing the larger change and
removing all occurrences but that would be a much larger
change.
Differential Revision: https://reviews.llvm.org/D33906
llvm-svn: 306731
Summary:
Implements PR889
Removing the virtual table pointer from Value saves 1% of RSS when doing
LTO of llc on Linux. The impact on time was positive, but too noisy to
conclusively say that performance improved. Here is a link to the
spreadsheet with the original data:
https://docs.google.com/spreadsheets/d/1F4FHir0qYnV0MEp2sYYp_BuvnJgWlWPhWOwZ6LbW7W4/edit?usp=sharing
This change makes it invalid to directly delete a Value, User, or
Instruction pointer. Instead, such code can be rewritten to a null check
and a call Value::deleteValue(). Value objects tend to have their
lifetimes managed through iplist, so for the most part, this isn't a big
deal. However, there are some places where LLVM deletes values, and
those places had to be migrated to deleteValue. I have also created
llvm::unique_value, which has a custom deleter, so it can be used in
place of std::unique_ptr<Value>.
I had to add the "DerivedUser" Deleter escape hatch for MemorySSA, which
derives from User outside of lib/IR. Code in IR cannot include MemorySSA
headers or call the MemoryAccess object destructors without introducing
a circular dependency, so we need some level of indirection.
Unfortunately, no class derived from User may have any virtual methods,
because adding a virtual method would break User::getHungOffOperands(),
which assumes that it can find the use list immediately prior to the
User object. I've added a static_assert to the appropriate OperandTraits
templates to help people avoid this trap.
Reviewers: chandlerc, mehdi_amini, pete, dberlin, george.burgess.iv
Reviewed By: chandlerc
Subscribers: krytarowski, eraman, george.burgess.iv, mzolotukhin, Prazek, nlewycky, hans, inglorion, pcc, tejohnson, dberlin, llvm-commits
Differential Revision: https://reviews.llvm.org/D31261
llvm-svn: 303362
Make personality functions, prefix data, and prologue data hungoff
operands of Function.
This is based on the email thread "[RFC] Clean up the way we store
optional Function data" on llvm-dev.
Thanks to sanjoyd, majnemer, rnk, loladiro, and dexonsmith for feedback!
Includes a fix to scrub value subclass data in dropAllReferences. Does not
use binary literals.
Differential Revision: http://reviews.llvm.org/D13829
llvm-svn: 256095
Make personality functions, prefix data, and prologue data hungoff
operands of Function.
This is based on the email thread "[RFC] Clean up the way we store
optional Function data" on llvm-dev.
Thanks to sanjoyd, majnemer, rnk, loladiro, and dexonsmith for feedback!
Includes a fix to scrub value subclass data in dropAllReferences.
Differential Revision: http://reviews.llvm.org/D13829
llvm-svn: 256093
Make personality functions, prefix data, and prologue data hungoff
operands of Function.
This is based on the email thread "[RFC] Clean up the way we store
optional Function data" on llvm-dev.
Thanks to sanjoyd, majnemer, rnk, loladiro, and dexonsmith for feedback!
Differential Revision: http://reviews.llvm.org/D13829
llvm-svn: 256090
Summary:
With this change, subclasses of `llvm::User` will be able to co-allocate
a variable number of bytes (called a "descriptor") with the `llvm::User`
instance. The co-allocated descriptor can later be accessed using
`llvm::User::getDescriptor`. This will be used in later changes to
implement operand bundles.
This change steals one bit from `NumUserOperands`, but given that it is
still 28 bits wide I don't think this will be a practical issue.
This change does not allow allocating hung off uses with descriptors.
This only for simplicity, not for any fundamental reason; and we can
easily add this functionality later if needed.
Reviewers: reames, chandlerc, dexonsmith, kmod, majnemer, pete, JosephTremoulet
Subscribers: pete, sanjoy, llvm-commits
Differential Revision: http://reviews.llvm.org/D12455
llvm-svn: 248453
This would have suppressed bug 24578, about use-after-
destroy on User and MDNode. Rolled back suppression for
the sake of code cleanliness, in preferance for bug
tracking to keep track of this issue.
This reverts commit 6ff2baabc4625d5b0a8dccf76aa0f72d930ea6c0.
llvm-svn: 246484
The patch is generated using this command:
tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
-checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \
llvm/lib/
Thanks to Eugene Kosov for the original patch!
llvm-svn: 240137
The personality routine currently lives in the LandingPadInst.
This isn't desirable because:
- All LandingPadInsts in the same function must have the same
personality routine. This means that each LandingPadInst beyond the
first has an operand which produces no additional information.
- There is ongoing work to introduce EH IR constructs other than
LandingPadInst. Moving the personality routine off of any one
particular Instruction and onto the parent function seems a lot better
than have N different places a personality function can sneak onto an
exceptional function.
Differential Revision: http://reviews.llvm.org/D10429
llvm-svn: 239940
Adds static_asserts to ensure alignment of concatenated objects is
correct, and fixes them where they are not.
Also changes the definition of AlignOf to use constexpr, except on
MSVC, to avoid enum comparison warnings from GCC.
(There's not too much of this in llvm itself, most of the fun is in
clang).
This seems to make LLVM actually work without Bus Error on 32bit
sparc.
Differential Revision: http://reviews.llvm.org/D10271
llvm-svn: 239872
For hung off uses, we need a Use* to tell use where the operands are.
This was User::OperandList but we want to remove that to save space
of all subclasses which aren't making use of 'hung off uses'.
Hung off uses now allocate their own 'OperandList' Use* in the
User::new which they call.
getOperandList() now uses the hung off uses bit to work out where the
Use* for the OperandList lives. If a User has hung off uses, then this
bit tells them to go back a single Use* from the User* and use that
value as the OperandList.
If a User has no hung off uses, then we get the first operand by
subtracting (NumOperands * sizeof(Use)) from the User this pointer.
This saves a pointer from User and all subclasses. Given the average
size of a subclass of User is 112 or 128 bytes, this saves around 7% of space
With malloc tending to align to 16-bytes the real saving is typically more like 3.5%.
On 'opt -O2 verify-uselistorder.lto.bc', peak memory usage prior to this change
is 149MB and after is 143MB so the savings are around 2.5% of peak.
Looking at some passes which allocate many Instructions and Values, parseIR drops
from 54.25MB to 52.21MB while the Inliner calls to Instruction::clone() drops
from 28.20MB to 27.05MB.
Reviewed by Duncan Exon Smith.
llvm-svn: 239623
There are now 2 versions of User::new. The first takes a size_t and is the current
implementation for subclasses which need 0 or more Use's allocated for their operands.
The new version takes no extra arguments to say that this subclass needs 'hung off uses'.
The HungOffUses bool is now set in this version of User::new and we can assert in
allocHungOffUses that we are allowed to have hung off uses.
This ensures we call the correct version of User::new for subclasses which need hung off uses.
A future commit will then allocate space for a single Use* which will be used
in place of User::OperandList once that field has been removed.
Reviewed by Duncan Exon Smith.
llvm-svn: 239622
This is to try make it very clear that subclasses shouldn't be changing
the value directly. Now that OperandList for normal instructions is computed
using the NumOperands, its critical that the NumOperands is accurate or we
could compute the wrong offset to the first operand.
I looked over all places which update NumOperands and they are all safe.
Hung off use User's don't use NumOperands to compute the OperandList so they
are safe to continue to manipulate it. The only other User which changed it
was GlobalVariable which has an optional init list but always allocated space
for a single Use. It was correctly setting NumOperands to 1 before setting an
initializer, and setting it to 0 after clearing the init list, so the order was safe.
Added some comments to that code to make sure that this isn't changed in future
without being aware of this constraint.
Reviewed by Duncan Exon Smith.
llvm-svn: 239621
We don't want anyone to access OperandList directly as its going to be removed
and computed instead. This uses getter's and setter's instead in which we
can later change the underlying implementation of OperandList.
Reviewed by Duncan Exon Smith.
llvm-svn: 239620
PhiNode, SwitchInst, LandingPad and IndirectBr all had virtually identical
logic for growing the hung off uses.
Move it to User so that they can all call a single shared implementation.
Their destructors were all empty after this change and were deleted. They all
have virtual clone_impl methods which can be used as vtable anchors.
Reviewed by Duncan Exon Smith.
llvm-svn: 239492
Now that the subclasses which care about hung off uses let ~User clean it up,
there's no need for a separate method. Just inline it to ~User and delete it.
Reviewed by Duncan Exon Smith.
llvm-svn: 239491
Currently all of the logic for deleting hung off uses, which PHI/switch/etc use,
is in their classes.
This adds a bit to Value which tracks whether that user had hung off uses,
then User can be responsible for clearing them instead of the sub classes.
Note, the bit used here was taken from NumOperands which was 30-bits.
Given the reduction to 29 bits, and the average User being just over 100 bytes,
a single User with 29-bits of num operands would need 50GB of RAM for itself
so its reasonable to assume that 29-bits is enough for now.
This is a step towards hiding all the hung off uses logic in the User.
Reviewed by Duncan Exon Smith.
llvm-svn: 239490
PhiNode's need to allocate space for an array of Use[N] and then BasicBlock*[N].
They had their own allocHungOffUses to handle all of this. This moves the logic
in to User::allocHungOffUses and PhiNode passes in a bool to say to allocate
the BB* space too.
Reviewed by Duncan Exon Smith.
llvm-svn: 239489
The patch is generated using clang-tidy misc-use-override check.
This command was used:
tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py \
-checks='-*,misc-use-override' -header-filter='llvm|clang' \
-j=32 -fix -format
http://reviews.llvm.org/D8925
llvm-svn: 234679
Store `User::NumOperands` (and `MDNode::NumOperands`) in `Value`.
On 64-bit host architectures, this reduces `sizeof(User)` and all
subclasses by 8, and has no effect on `sizeof(Value)` (or, incidentally,
on `sizeof(MDNode)`).
On 32-bit host architectures, this increases `sizeof(Value)` by 4.
However, it has no effect on `sizeof(User)` and `sizeof(MDNode)`, so the
only concrete subclasses of `Value` that actually see the increase are
`BasicBlock`, `Argument`, `InlineAsm`, and `MDString`. Moreover, I'll
be shocked and confused if this causes a tangible memory regression.
This has no functionality change (other than memory footprint).
llvm-svn: 219845
A follow-up commit will modify the memory-layout of `Value`, `User`, and
`MDNode`. First fix the comments to be doxygen-friendly (and to follow
the coding standards).
- Use "\brief" instead of "repeatedName -".
- Add a brief intro where it was missing.
- Remove duplicated comments from source files (and a couple of
noisy/trivial comments altogether).
llvm-svn: 219844
requiring full control over the various parameters to the std::iterator
concept / trait thing. This is a precursor for adjusting these things to
where you can write a bidirectional iterator wrapping a random access
iterator with custom increment and decrement logic.
llvm-svn: 207487
this code ages ago and lost track of it. Seems worth doing though --
this thing can get called from places that would benefit from knowing
that std::distance is O(1). Also add a very fledgeling unittest for
Users and make sure various aspects of this seem to work reasonably.
llvm-svn: 206453
out-of-line so that it can refer to the methods on User. As
a consequence, this removes the need to define one template method if
value_use_iterator in the extremely strange User.h header (!!!).
This makse Use.h slightly less peculiar. The only remaining real
peculiarity is the definition of Use::set in Value.h
llvm-svn: 202805
a constructor either. Just call the constructor directly. I'll look into
making this work with aggregate initialization some other time (when
I have someone with MSVC 2012 handy to test ideas).
llvm-svn: 202688
operand_values. The first provides a range view over operand Use
objects, and the second provides a range view over the Value*s being
used by those operands.
The naming is "STL-style" rather than "LLVM-style" because we have
historically named iterator methods STL-style, and range methods seem to
have far more in common with their iterator counterparts than with
"normal" APIs. Feel free to bikeshed on this one if you want, I'm happy
to change these around if people feel strongly.
I've switched code in SROA and LCG to exercise these mostly to ensure
they work correctly -- we don't really have an easy way to unittest this
and they're trivial.
llvm-svn: 202687