| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 193350
|
|
|
|
| |
llvm-svn: 193344
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 193251
|
|
|
|
|
|
| |
expanded. PR8976.
llvm-svn: 193014
|
|
|
|
| |
llvm-svn: 193012
|
|
|
|
| |
llvm-svn: 193009
|
|
|
|
|
|
| |
the Erlang GC implementation.
llvm-svn: 193008
|
|
|
|
|
|
|
|
|
|
|
| |
Thanks to Daniel Berlin and Nadav Rotem for feedback and rewording!
Discussion:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20131014/191677.html
Reviewed by: nrotem, dberlin
llvm-svn: 192958
|
|
|
|
|
|
|
| |
Aliases now have their own section where we document which linkages they can
have.
llvm-svn: 192825
|
|
|
|
| |
llvm-svn: 192796
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 192679
|
|
|
|
| |
llvm-svn: 192479
|
|
|
|
| |
llvm-svn: 192304
|
|
|
|
| |
llvm-svn: 192265
|
|
|
|
|
|
| |
Thanks to Sean Silva for noticing it.
llvm-svn: 192102
|
|
|
|
|
|
| |
This will be used to extend constructor aliases in clang.
llvm-svn: 192066
|
|
|
|
| |
llvm-svn: 191752
|
|
|
|
|
|
| |
It now points to the equivalent page on imgtec.com
llvm-svn: 191658
|
|
|
|
| |
llvm-svn: 191561
|
|
|
|
| |
llvm-svn: 191425
|
|
|
|
| |
llvm-svn: 191219
|
|
|
|
|
|
| |
Thanks to Hal Finkel for noticing it.
llvm-svn: 191216
|
|
|
|
|
|
|
|
|
| |
Previous discussion:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-July/063909.html
Differential Revision: http://llvm-reviews.chandlerc.com/D1191
llvm-svn: 190773
|
|
|
|
| |
llvm-svn: 190696
|
|
|
|
| |
llvm-svn: 190569
|
|
|
|
| |
llvm-svn: 190552
|
|
|
|
| |
llvm-svn: 190492
|
|
|
|
|
|
| |
Adornments need to be at least as long as the thing they adorn.
llvm-svn: 190327
|
|
|
|
| |
llvm-svn: 190326
|
|
|
|
| |
llvm-svn: 190324
|
|
|
|
| |
llvm-svn: 190282
|
|
|
|
| |
llvm-svn: 189839
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 189732
|
|
|
|
|
|
| |
This is under active discussion.
llvm-svn: 189730
|
|
|
|
|
|
|
| |
implementation files. While doc generation systems don't need this,
humans do benefit from it. Not everyone reads all code through doxygen.
llvm-svn: 189704
|
|
|
|
| |
llvm-svn: 189593
|
|
|
|
|
|
|
|
|
| |
make EXTRA_SEARCH_MAPPINGS a "dumb" variable.
I do not think the massaging that I was doing for EXTRA_SEARCH_MAPPINGS was
truly necessary.
llvm-svn: 189522
|
|
|
|
| |
llvm-svn: 189507
|
|
|
|
|
|
| |
documentation for llvm/all subprojects. Renamed llvm's doxygen generation command to doxygen-llvm.
llvm-svn: 189506
|
|
|
|
| |
llvm-svn: 189210
|
|
|
|
|
|
|
| |
I am going to add in a subsequent patch support for generating the llvm
manpage.
llvm-svn: 189164
|
|
|
|
|
|
|
|
| |
This function attribute indicates that the function is not optimized
by any optimization or code generator passes with the
exception of interprocedural optimization passes.
llvm-svn: 189101
|
|
|
|
| |
llvm-svn: 188943
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
llvm-svn: 188728
|
|
|
|
| |
llvm-svn: 188627
|
|
|
|
| |
llvm-svn: 188589
|
|
|
|
| |
llvm-svn: 188382
|
|
|
|
|
|
|
| |
As Ben pointed out, GAS doesn't support this syntax so we should give at least
some warning that it might not be portable.
llvm-svn: 188377
|
|
|
|
| |
llvm-svn: 188195
|
|
|
|
| |
llvm-svn: 188191
|