libclang uses a CrashRecoveryContext, and building a module does too. If a
module gets built through libclang, nested CrashRecoveryContexts are used. They
work fine with threads as things are stored in ThreadLocal variables, but in
LLVM_ENABLE_THREADS=OFF builds the two recovery contexts would write to the
same globals.
To fix, keep active CrashRecoveryContextImpls in a list and have the global
point to the innermost one, and do something similar for
tlIsRecoveringFromCrash.
Necessary (but not sufficient) for PR11974 and PR20325
http://reviews.llvm.org/D11770
llvm-svn: 244251
iisUnmovableInstruction() had a list of instructions hardcoded which are
considered unmovable. The list lacked (at least) an entry for the va_arg
and cmpxchg instructions.
Fix this by introducing a new Instruction::mayBeMemoryDependent()
instead of maintaining another instruction list.
Patch by Matthias Braun <matze@braunis.de>.
Differential Revision: http://reviews.llvm.org/D11577
rdar://problem/22118647
llvm-svn: 244244
It adds a new constructor, which takes a std::function predicate function that
is run at the beginning of shrink wrapping to determine whether the optimization
should run on the given machine function. The std::function can be overridden by
each target, allowing target-specific decisions to be made on each machine
function.
This is necessary for PowerPC, as the decision to run shrink wrapping is
partially based on the ABI. Futhermore, this operates nicely with the GCC iFunc
capability, which allows option overrides on a per-function basis.
Phabricator: http://reviews.llvm.org/D11421
llvm-svn: 244235
This is the first mechanical step in preparation for making this and all
the other alias analysis passes available to the new pass manager. I'm
factoring out all the totally boring changes I can so I'm moving code
around here with no other changes. I've even minimized the formatting
churn.
I'll reformat and freshen comments on the interface now that its located
in the right place so that the substantive changes don't triger this.
llvm-svn: 244197
around a DataLayout interface in favor of directly querying DataLayout.
This wrapper specifically helped handle the case where this no
DataLayout, but LLVM now requires it simplifynig all of this. I've
updated callers to directly query DataLayout. This in turn exposed
a bunch of places where we should have DataLayout readily available but
don't which I've fixed. This then in turn exposed that we were passing
DataLayout around in a bunch of arguments rather than making it readily
available so I've also fixed that.
No functionality changed.
llvm-svn: 244189
This commit implements the initial serialization of the machine operand target
flags. It extends the 'TargetInstrInfo' class to add two new methods that help
to provide text based serialization for the target flags.
This commit can serialize only the X86 target flags, and the target flags for
the other targets will be serialized in the follow-up commits.
Reviewers: Duncan P. N. Exon Smith
llvm-svn: 244185
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
Summary:
Emit both DWARF and CodeView if "CodeView" and "Dwarf Version" module
flags are set.
Reviewers: majnemer
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D11756
llvm-svn: 244158
1. Create a utility function normalizeEdgeWeights() in MachineBranchProbabilityInfo that normalizes a list of edge weights so that the sum of then can fit in uint32_t.
2. Provide an interface in MachineBasicBlock to normalize its successors' weights.
3. Add a flag in MachineBasicBlock that tracks whether its successors' weights are normalized.
4. Provide an overload of getSumForBlock that accepts a non-const pointer to a MBB so that it can force normalizing this MBB's successors' weights.
5. Update several uses of getSumForBlock() by eliminating the once needed weight scale.
Differential Revision: http://reviews.llvm.org/D11442
llvm-svn: 244154
pass manager.
This never worked, and won't ever work. It was actually why I ended up
building the LazyCallGraph set of code which is more more effectively
wired up to the new pass manager. This accidentally got committed when
I was trying to land a cleanup of the code organization in the other
parts of this file. =[ My bad, but fortunately Dave was keen eyed enough
to spot that this code couldn't possibly work. =]
llvm-svn: 244127
The only place that tries to return a CallGraph by value
(CallGraphAnalysis::run) doesn't seem to be used right now, but it's a
reasonable bit of cleanup anyway.
llvm-svn: 244122
LoadedObjectInfo was depending on the implicit copy ctor in the presence
of a user-declared dtor. Default (and protect) it in the base class and
make the devired classes final to avoid any risk of a public API that
would enable slicing.
llvm-svn: 244112
rather than 'unsigned' for their costs.
For something like costs in particular there is a natural "negative"
value, that of savings or saved cost. As a consequence, there is a lot
of code that subtracts or creates negative values based on cost, all of
which is prone to awkwardness or bugs when dealing with an unsigned
type. Similarly, we *never* want these values to wrap, as that would
cause Very Bad code generation (likely percieved as an infinite loop as
we try to emit over 2^32 instructions or some such insanity).
All around 'int' seems a much better fit for these basic metrics. I've
added asserts to ensure that at least the TTI interface never returns
negative numbers here. If we ever have a use case for negative numbers,
we can remove this, but this way a bug where someone used '-1' to
produce a 'very large' cost will be caught by the assert.
This passes all tests, and is also UBSan clean.
No functional change intended.
Differential Revision: http://reviews.llvm.org/D11741
llvm-svn: 244080
To get the successors of a BB we currently do successors(BB) which
ultimately walks the successors of the BB's terminator.
This moves the iterator to TerminatorInst as thats what we're actually
using to do the iteration, and adds a member function to TerminatorInst
to allow us to iterate directly over successors given an instruction.
For example, we can now do
for (auto *Succ : BI->successors())
instead of
for (unsigned i = 0, e = BI->getNumSuccessors(); i != e; ++i)
Reviewed by Tobias Grosser.
llvm-svn: 244074
Create wrapper methods in the Function class for the OptimizeForSize and MinSize
attributes. We want to hide the logic of "or'ing" them together when optimizing
just for size (-Os).
Currently, we are not consistent about this and rely on a front-end to always set
OptimizeForSize (-Os) if MinSize (-Oz) is on. Thus, there are 18 FIXME changes here
that should be added as follow-on patches with regression tests.
This patch is NFC-intended: it just replaces existing direct accesses of the attributes
by the equivalent wrapper call.
Differential Revision: http://reviews.llvm.org/D11734
llvm-svn: 243994
If we don't have sys/wait.h and we're on a unix system there's no way
that several of the llvm tools work at all. This includes clang.
Just remove the configure and cmake checks entirely - we'll get a
build error instead of building something broken now.
llvm-svn: 243957
Summary: This patch adds enum value for an existing metadata type -- make.implicit. Using preassigned enum will be helpful to get compile time type checking and avoid string construction and comparison. The patch also changes uses of make.implicit from string metadata to enum metadata. There is no functionality change.
Reviewers: reames
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D11698
llvm-svn: 243954
This happens to work, but is not guaranteed to work. Indeed, most memcpy
interfaces in Linux-land annotate these arguments as nonnull, and GCC
and LLVM both can and do optimized based upon that. When they do so,
they might legitimately have miscompiled code calling this routine with
two valid iterators, 'nullptr' and 'nullptr'. There was even code doing
precisely this because StringRef().begin() and StringRef().end() both
produce null pointers.
This was found by UBSan.
llvm-svn: 243927
Various value handles needed to be copy constructible and copy
assignable (mostly for their use in DenseMap). But to avoid an API that
might allow accidental slicing, make these members protected in the base
class and make derived classes final (the special members become
implicitly public there - but disallowing further derived classes that
might be sliced to the intermediate type).
Might be worth having a warning a bit like -Wnon-virtual-dtor that
catches public move/copy assign/ctors in classes with virtual functions.
(suppressable in the same way - by making them protected in the base,
and making the derived classes final) Could be fancier and only diagnose
them when they're actually called, potentially.
Also allow a few default implementations where custom implementations
(especially with non-standard return types) were implemented.
llvm-svn: 243909
This fixes a bug found while working on the bitcode reader. In
particular, the method BitstreamReader::AtEndOfStream doesn't always
behave correctly when processing a data streamer. The method
fillCurWord doesn't properly set CurWord/BitsInCurWord if the data
streamer was already at eof, but GetBytes had not yet set the
ObjectSize field of the streaming memory object.
This patch fixes this problem, and provides a test to show that
this problem has been fixed.
Patch by Karl Schimpf.
Differential Revision: http://reviews.llvm.org/D11391
llvm-svn: 243890
Since r241097, `DIBuilder` has only created distinct `DICompileUnit`s.
The backend is liable to start relying on that (if it hasn't already),
so make uniquable `DICompileUnit`s illegal and automatically upgrade old
bitcode. This is a nice cleanup, since we can remove an unnecessary
`DenseSet` (and the associated uniquing info) from `LLVMContextImpl`.
Almost all the testcases were updated with this script:
git grep -e '= !DICompileUnit' -l -- test |
grep -v test/Bitcode |
xargs sed -i '' -e 's,= !DICompileUnit,= distinct !DICompileUnit,'
I imagine something similar should work for out-of-tree testcases.
llvm-svn: 243885
Instead of cloning distinct `MDNode`s when linking in a module, just
move them over. The module linker destroys the source module, so the
old node would otherwise just be leaked on the context. Create the new
node in place. This also reduces the number of cloned uniqued nodes
(since it's less likely their operands have changed).
This mapping strategy is only correct when we're discarding the source,
so the linker turns it on via a ValueMapper flag, `RF_MoveDistinctMDs`.
There's nothing observable in terms of `llvm-link` output here: the
linked module should be semantically identical.
I'll be adding more 'distinct' nodes to the debug info metadata graph in
order to break uniquing cycles, so the benefits of this will partly come
in future commits. However, we should get some gains immediately, since
we have a fair number of 'distinct' `DILocation`s being linked in.
llvm-svn: 243883
Instead of always showing/printing all functions, a class derived from
the DOTViewer class can overwrite the set of functions that will be
processed.
This will be used (and tested) by Polly's scop viewers, but other users
can be imagined as well.
llvm-svn: 243881
Summary:
This is useful for PNaCl's `RewriteAtomics` pass. NaCl intrinsics don't exist for some of the more exotic RMW instructions, so by refactoring this function into its own, `RewriteAtomics` can share code rewriting those atomics with `AtomicExpand` while additionally saving a few cycles by generating the `cmpxchg` NaCl-specific intrinsic with the callback. Without this patch, `RewriteAtomics` would require two extra passes over functions, by first requiring use of the full `AtomicExpand` pass to just expand the leftover exotic RMWs and then running itself again to expand resulting `cmpxchg`s.
NFC
Reviewers: jfb
Subscribers: jfb, llvm-commits
Differential Revision: http://reviews.llvm.org/D11422
llvm-svn: 243880
Summary:
Modify the cost calculation function for interleaved accesses
to use the target-specific costs for insert/extract element and
memory operations.
This better models the case where the backend can't match
the interleaved group, and we are forced to use a wide load
and shuffle vectors.
Interleaved accesses are not enabled by default, so this shouldn't
cause a performance change.
Reviewers: jmolloy
Subscribers: jmolloy, llvm-commits
Differential Revision: http://reviews.llvm.org/D11718
llvm-svn: 243875
