| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 104750
|
| |
|
|
| |
llvm-svn: 104703
|
| |
|
|
| |
llvm-svn: 104391
|
| |
|
|
|
|
| |
used in Autogen.sh
llvm-svn: 104113
|
| |
|
|
|
|
|
| |
to LLVM_LIBRARY_VISIBILITY and introduce LLVM_GLOBAL_VISIBILITY, which is
the opposite, for future use by dragonegg.
llvm-svn: 103495
|
| |
|
|
| |
llvm-svn: 103479
|
| |
|
|
| |
llvm-svn: 103478
|
| |
|
|
| |
llvm-svn: 103477
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add documentation for:
-dot-dom
-dot-dom-only
-dot-postdom
-dot-postdom-only
-view-dom
-view-dom-only
-view-postdom
-view-postdom-only
llvm-svn: 103251
|
| |
|
|
| |
llvm-svn: 103219
|
| |
|
|
|
|
|
| |
configured via --enable-doxygen. It seems some systems have broken pdfroff
so automatic use of it is not safe.
llvm-svn: 103217
|
| |
|
|
| |
llvm-svn: 103215
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
NOTE: 2nd part changeset for cfe trunk to follow.
*** PRE-PATCH ISSUES ADDRESSED
- clang api docs fail build from objdir
- clang/llvm api docs collide in install PREFIX/
- clang/llvm main docs collide in install
- clang/llvm main docs have full of hard coded destination
assumptions and make use of absolute root in static html files;
namely CommandGuide tools hard codes a website destination
for cross references and some html cross references assume
website root paths
*** IMPROVEMENTS
- bumped Doxygen from 1.4.x -> 1.6.3
- splits llvm/clang docs into 'main' and 'api' (doxygen) build trees
- provide consistent, reliable doc builds for both main+api docs
- support buid vs. install vs. website intentions
- support objdir builds
- document targets with 'make help'
- correct clean and uninstall operations
- use recursive dir delete only where absolutely necessary
- added call function fn.RMRF which safeguards against botched 'rm -rf';
if any target (or any variable is evaluated) which attempts
to remove any dirs which match a hard-coded 'safelist', a verbose
error will be printed and make will error-stop.
llvm-svn: 103213
|
| |
|
|
| |
llvm-svn: 103134
|
| |
|
|
| |
llvm-svn: 103024
|
| |
|
|
| |
llvm-svn: 103023
|
| |
|
|
| |
llvm-svn: 102978
|
| |
|
|
|
|
|
|
|
|
| |
update the big red warning at the top. Most of the old content remains
and awaits revision.
Clear out the API changes section, and start it up again with a
mention of the add->fadd transition.
llvm-svn: 102977
|
| |
|
|
|
|
| |
concept in the proposed memory model changes.
llvm-svn: 102911
|
| |
|
|
|
|
|
| |
respect to padding bytes isn't something that the dependence text
needs to spell out.
llvm-svn: 102910
|
| |
|
|
|
|
|
| |
terminator instructions so that it applies to all terminators with
multiple successors, including invoke.
llvm-svn: 102909
|
| |
|
|
|
|
| |
constant expressions as well as instructions.
llvm-svn: 102908
|
| |
|
|
|
|
|
| |
Remove the -enable-eh option which is only used by the JIT,
and replace it with -jit-enable-eh.
llvm-svn: 102865
|
| |
|
|
| |
llvm-svn: 102741
|
| |
|
|
| |
llvm-svn: 102740
|
| |
|
|
|
|
|
|
|
|
| |
of dependence and define trap values in terms of dependence, instead
of trying to cover the concept with a flurry of ad-hoc rules.
The dependence model isn't complete yet, but it's already much more
rigorous than the description it replaces.
llvm-svn: 102479
|
| |
|
|
| |
llvm-svn: 102478
|
| |
|
|
|
|
|
| |
to not increase the alignment of globals with an assigned
alignment and section.
llvm-svn: 102476
|
| |
|
|
|
|
|
| |
it is not generally valid for targets to overalign
them when an alignment is specified.
llvm-svn: 102474
|
| |
|
|
| |
llvm-svn: 102418
|
| |
|
|
| |
llvm-svn: 102417
|
| |
|
|
|
|
|
|
|
| |
traps flowing through memory references, add some text to
better cover phi nodes and externally-visible side effects,
add an example of instructions being control-dependent
on a trap value, and reword some of the existing trap rules.
llvm-svn: 102399
|
| |
|
|
|
|
|
| |
intrinsics have volatile semantics in addition to the load and store
instructions.
llvm-svn: 102384
|
| |
|
|
|
|
| |
onto control-dependent instructions.
llvm-svn: 102381
|
| |
|
|
| |
llvm-svn: 102378
|
| |
|
|
| |
llvm-svn: 102376
|
| |
|
|
| |
llvm-svn: 102354
|
| |
|
|
| |
llvm-svn: 102352
|
| |
|
|
| |
llvm-svn: 102319
|
| |
|
|
| |
llvm-svn: 102318
|
| |
|
|
|
|
| |
the release notes.
llvm-svn: 102309
|
| |
|
|
| |
llvm-svn: 102278
|
| |
|
|
| |
llvm-svn: 102276
|
| |
|
|
| |
llvm-svn: 102175
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the definition of the nsw and nuw flags to make use of it.
nsw was introduced to help optimizers answer yes to the following:
// Can we change i from i32 to i64 to eliminate the cast inside the loop?
for (int i = 0; i < n; ++i) A[i] *= 0.1;
// Can we assume that this loop will eventually terminate?
for (int i = 0; i <= n; ++i) A[i] *= 0.1;
In its current form, it isn't truly sufficient for either.
In the first case, if the increment overflows, it'll still have some
valid i32 value; sign-extending it will produce a value which is 33
homogeneous sign bits trailed by 31 independent undef bits. If i is
promoted to i64, it won't have those same values when it reaches that
point. (The compiler could recover here by reasoning about how i is
used by the load, but that's a lot more complicated and isn't always
possible.)
In the second case, there is no value for i which will be greater than
n, so having the increment return undef on overflow doesn't help.
Trap values are a formalization of some existing concepts that we have
about LLVM IR, and give the optimizers a better basis for answering yes
to both questions above.
llvm-svn: 102140
|
| |
|
|
| |
llvm-svn: 102132
|
| |
|
|
| |
llvm-svn: 102126
|
| |
|
|
| |
llvm-svn: 102125
|
| |
|
|
| |
llvm-svn: 102124
|
| |
|
|
| |
llvm-svn: 102121
|