Major steps include:
1). introduces a not-addr-taken bit-field in GlobalVariable
2). GlobalOpt pass sets "not-address-taken" if it proves a global varirable
dosen't have its address taken.
3). AA use this info for disambiguation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193251 91177308-0d34-0410-b5e6-96231b3b80d8
There doesn't seem to be a need in checking if a directory exists if we
will just rm -rf it once we affirm that it does. Instead, just blindly
try to delete it.
This fixes PR17541.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192679 91177308-0d34-0410-b5e6-96231b3b80d8
part of getting started with LLVM.
The LLVM getting started document is in woeful need of attention. I may
get to some of this, but some random notes for folks interested:
1) We need to separate the getting started steps for folks who are
interested in the core LLVM libs and nothing else, folks interested
in a nifty C++ toolchain and nothing else, and folks interested in
both.
2) We should include documentation for both release archives, svn, and
git in equal portion, and we should document all of the various
repositories of interest: llvm, clang, clang-tools-extra,
compiler-rt, lld, libcxx, test-suite.
3) We should document the CMake build. We should probably document the
CMake build first, and give a fall-back set of docs for the Makefile
build for the use cases where that is still the preferred solution.
This would more closely match the use cases that folks in the open
source community are likely to have, and would remove a point of
discrepancy between Linux, Windows, and Mac instructions.
4) Probably a ton of other modernization stuff that I've not thought of
here.
Anyways, if anyone at all is interested, please help clean up this
document. It is much needed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189732 91177308-0d34-0410-b5e6-96231b3b80d8
implementation files. While doc generation systems don't need this,
humans do benefit from it. Not everyone reads all code through doxygen.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189704 91177308-0d34-0410-b5e6-96231b3b80d8
This function attribute indicates that the function is not optimized
by any optimization or code generator passes with the
exception of interprocedural optimization passes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189101 91177308-0d34-0410-b5e6-96231b3b80d8
This adds a llvm.copysign intrinsic; We already have Libfunc recognition for
copysign (which is turned into the FCOPYSIGN SDAG node). In order to
autovectorize calls to copysign in the loop vectorizer, we need a corresponding
intrinsic as well.
In addition to the expected changes to the language reference, the loop
vectorizer, BasicTTI, and the SDAG builder (the intrinsic is transformed into
an FCOPYSIGN node, just like the function call), this also adds FCOPYSIGN to a
few lists in LegalizeVector{Ops,Types} so that vector copysigns can be
expanded.
In TargetLoweringBase::initActions, I've made the default action for FCOPYSIGN
be Expand for vector types. This seems correct for all in-tree targets, and I
think is the right thing to do because, previously, there was no way to generate
vector-values FCOPYSIGN nodes (and most targets don't specify an action for
vector-typed FCOPYSIGN).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188728 91177308-0d34-0410-b5e6-96231b3b80d8
As Ben pointed out, GAS doesn't support this syntax so we should give at least
some warning that it might not be portable.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188377 91177308-0d34-0410-b5e6-96231b3b80d8
