AliasSetTracker::addUnknown may create an AliasSet devoid of pointers
just to contain an instruction if no suitable AliasSet already exists.
It will then AliasSet::addUnknownInst and we will be done.
However, it's possible for addUnknown to choose an existing AliasSet to
addUnknownInst.
If this were to occur, we are in a bit of a pickle: removing pointers
from the AliasSet can cause the entire AliasSet to become destroyed,
taking our unknown instructions out with them.
Instead, keep track whether or not our AliasSet has any unknown
instructions.
This fixes PR21582.
llvm-svn: 222338
This is to be consistent with StringSet and ultimately with the standard
library's associative container insert function.
This lead to updating SmallSet::insert to return pair<iterator, bool>,
and then to update SmallPtrSet::insert to return pair<iterator, bool>,
and then to update all the existing users of those functions...
llvm-svn: 222334
Using AA during CodeGen is very useful for in-order cores. It is less useful for ooo cores. Also I find
enabling useAA for Cortex-A57 may generate worse code for some test cases. If useAA in codegen is improved
and benefical for ooo cores, we can enable it again.
llvm-svn: 222333
SeparateConstOffsetFromGEP can gives more optimizaiton opportunities related to GEPs, which benefits EarlyCSE
and LICM. By enabling these passes we can have better address calculations and generate a better addressing
mode. Some SPEC 2006 benchmarks (astar, gobmk, namd) have obvious improvements on Cortex-A57.
Reviewed in http://reviews.llvm.org/D5864.
llvm-svn: 222331
This reverts commit r222310.
Not sure which commit is the cause of the failure on the darwin bot. Will need
to revert my changes and commit one change at a time.
llvm-svn: 222330
If LowerGEP is enabled, it can lower a GEP with multiple indices into GEPs with a single index
or arithmetic operations. Lowering GEPs can always extract structure indices. Lowering GEPs can
also give use more optimization opportunities. It can benefit passes like CSE, LICM and CGP.
Reviewed in http://reviews.llvm.org/D5864
llvm-svn: 222328
Having two ways to do this doesn't seem terribly helpful and
consistently using the insert version (which we already has) seems like
it'll make the code easier to understand to anyone working with standard
data structures. (I also updated many references to the Entry's
key and value to use first() and second instead of getKey{Data,Length,}
and get/setValue - for similar consistency)
Also removes the GetOrCreateValue functions so there's less surface area
to StringMap to fix/improve/change/accommodate move semantics, etc.
llvm-svn: 222319
The standard requires that nullptr_t can be reinterpret_cast to an integral type
at least the size of nullptr_t. There is no way to emulate this conversion in
the C++03 nullptr_t implementation. The test for this conversion has been moved
to a new test and marked XFAIL with c++03.
This recommits what was originally r222296.
llvm-svn: 222318
StringSet is still a bit dodgy in that it exposes the raw iterator of
the StringMap parent, which exposes the weird detail that StringSet
actually has a 'value'... but anyway, this is useful for a handful of
clients that want to reference the newly inserted/persistent string data
in the StringSet/Map/Entry/thing.
llvm-svn: 222302
where it is retrieving the Return Address register contents
on a target where that's a thing. If we fail to get a valid
RA, we force a switch to the fallback unwind plan. This patch
adds a sanity check for that fallback unwind plan -- it must
get a valid CFA for this frame in addition to being able to
retrieve the caller's PC -- and it correctly marks the unwind
rules as failing if the fallback unwind plan fails.
<rdar://problem/19010211>
llvm-svn: 222301
Mach-o does not use a simple SO_NEEDED to track dependent dylibs. Instead,
the linker copies four things from each dylib to each client: the runtime path
(aka "install name"), the build time, current version (dylib build number), and
compatibility version The build time is no longer used (it cause every rebuild
of a dylib to be different). The compatibility version is usually just 1.0
and never changes, or the dylib becomes incompatible.
This patch copies that information into the NormalizedMachO format and
propagates it to clients.
llvm-svn: 222300
It printed out base relocation table header as table entry.
This patch also makes llvm-readobj to not skip ABSOLUTE entries
becuase it was confusing.
llvm-svn: 222299
Wrap the original test in _LIBCPP_HAS_QUICK_EXIT so it only runs when we have
quick_exit and add two new tests that check that when _LIBCPP_HAS_QUICK_EXIT
is not defined then no definition of std::at_quick_exit or std::quick_exit are
available.
llvm-svn: 222298
Reviewed at http://reviews.llvm.org/D6238
ASan on Darwin during launch reads DYLD_INSERT_LIBRARIES env. variable and if it's not set or if the ASan dylib is not present in there, it relaunches the process. The check whether the dylib is present in the variable is now trying to find a full path in there. This fails in the scenarios where we want to copy the dylib to the executable's directory or somewhere else and set the DYLD_INSERT_LIBRARIES manually, see http://reviews.llvm.org/D6018.
Let's change the search in DYLD_INSERT_LIBRARIES to only look for the filename of the dylib and not the full path.
llvm-svn: 222297
some commands that will get run if the target crashes.
Also fix the bug where the local .lldbinit file was not getting
sourced before not after the target was created from the file options on the
driver command line.
<rdar://problem/19019843>
llvm-svn: 222295
The other option would be to do something like
if (that.isSingleWord())
VAL = that.VAL;
else
pVal = that.pVal
This bug was causing 86TTI::getIntImmCost to be miscompiled in a LTO
bootstrap in stage2, causing the build of stage3 to fail.
LLVM is getting quiet good at exploiting this. Not sure if there is anything
a sanitizer could do to help
llvm-svn: 222294
This patch fixes the following MSVC warning.
warning C4334: '<<' : result of 32-bit shift implicitly
converted to 64 bits (was 64-bit shift intended?)
llvm-svn: 222293