configure expects LLVM Test Suite to be in projects/test-suite.
Made the "getting started" and "testing infrastructure" docs internally consistent.
Avoid confusion between llvm-test and llvm/test.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@114691 91177308-0d34-0410-b5e6-96231b3b80d8
Triple class constructor. Only valid triples should now be used
inside LLVM - front-ends are now responsable for rejecting or
correcting invalid target triples. The Triple::normalize method
can be used to straighten out funky triples provided by users.
Give this a whirl through the buildbots to see if I caught all
places where triples enter LLVM.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112470 91177308-0d34-0410-b5e6-96231b3b80d8
It's similar to "linker_private_weak", but it's known that the address of the
object is not taken. For instance, functions that had an inline definition, but
the compiler decided not to inline it. Note, unlike linker_private and
linker_private_weak, linker_private_weak_def_auto may have only default
visibility. The symbols are removed by the linker from the final linked image
(executable or dynamic library).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@111684 91177308-0d34-0410-b5e6-96231b3b80d8
instead of DejaGNU. Still a bit kooky, since the current test format still has
some strong Tcl roots. Oh well!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@110005 91177308-0d34-0410-b5e6-96231b3b80d8
official recommendation is to use LNT instead. I will write docs on setting up
an LNT installation for submission to llvm.org, one day.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@110004 91177308-0d34-0410-b5e6-96231b3b80d8
Simplifying use_iterators by dereferencing
is not a good idea. The codebase does not depend
in this any more, and it may introduce hidden
runtime cost. If you get compile errors, please
dereference your iterator before passing to cast<>
(and friends).
Also: please consider caching the result of
operator* and reusing that instead of dereferencing
many times.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@109425 91177308-0d34-0410-b5e6-96231b3b80d8
The RegionInfo pass detects single entry single exit regions in a function,
where a region is defined as any subgraph that is connected to the remaining
graph at only two spots.
Furthermore an hierarchical region tree is built.
Use it by calling "opt -regions analyze" or "opt -view-regions".
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@109089 91177308-0d34-0410-b5e6-96231b3b80d8
Make MDNode::destroy private.
Fix the one thing that used MDNode::destroy, outside of MDNode itself.
One should never delete or destroy an MDNode explicitly. MDNodes
implicitly go away when there are no references to them (implementation
details aside).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@109028 91177308-0d34-0410-b5e6-96231b3b80d8
Targets must now implement TargetInstrInfo::copyPhysReg instead. There is no
longer a default implementation forwarding to copyRegToReg.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@108095 91177308-0d34-0410-b5e6-96231b3b80d8
interface needs implementations to be consistent, so any code which
wants to support different semantics must use a different interface.
It's not currently worthwhile to add a new interface for this new
concept.
Document that AliasAnalysis doesn't support cross-function queries.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@107776 91177308-0d34-0410-b5e6-96231b3b80d8
builds to "Release". The default build is unchanged (optimization on,
assertions on), however it is now called Release+Asserts. The intent
is that future LLVM releases released via llvm.org will be Release builds
in the new sense, i.e. will have assertions disabled (currently they have
assertions enabled, for a more than 20% slowdown). This will bring them
in line with MacOS releases, which ship with assertions disabled. It also
means that "Release" now means the same things in make and cmake builds:
cmake already disables assertions for "Release" builds AFAICS.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@107758 91177308-0d34-0410-b5e6-96231b3b80d8
the noalias argument on function attributes be usable to model the
C99 restrict keyword on arguments, and to allow AliasAnalysis to
consider a noalias-attributed argument to be an "identified object".
To support this, refactor a new "based on" concept out of the current
pointer aliasing "associated" concept. This "based on" concept is very
similar to (though it is not identical with) the "based on" concept
in C99.
Also, reword the definition of NoAlias to more closely describe the
concept that the optimizer uses.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@107495 91177308-0d34-0410-b5e6-96231b3b80d8
Objective-C metadata types which should be marked as "weak", but which the
linker will remove upon final linkage. However, this linkage isn't specific to
Objective-C.
For example, the "objc_msgSend_fixup_alloc" symbol is defined like this:
.globl l_objc_msgSend_fixup_alloc
.weak_definition l_objc_msgSend_fixup_alloc
.section __DATA, __objc_msgrefs, coalesced
.align 3
l_objc_msgSend_fixup_alloc:
.quad _objc_msgSend_fixup
.quad L_OBJC_METH_VAR_NAME_1
This is different from the "linker_private" linkage type, because it can't have
the metadata defined with ".weak_definition".
Currently only supported on Darwin platforms.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@107433 91177308-0d34-0410-b5e6-96231b3b80d8
metadata types which should be marked as "weak", but which the linker will
remove upon final linkage. For example, the "objc_msgSend_fixup_alloc" symbol is
defined like this:
.globl l_objc_msgSend_fixup_alloc
.weak_definition l_objc_msgSend_fixup_alloc
.section __DATA, __objc_msgrefs, coalesced
.align 3
l_objc_msgSend_fixup_alloc:
.quad _objc_msgSend_fixup
.quad L_OBJC_METH_VAR_NAME_1
This is different from the "linker_private" linkage type, because it can't have
the metadata defined with ".weak_definition".
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@107205 91177308-0d34-0410-b5e6-96231b3b80d8
lib/Transforms/Hello/Makefile, and prevents a lot of errors like "Assertion
`Inserted && "Pass registered multiple times!"' failed"
Patch by Gregory Petrosyan!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@106471 91177308-0d34-0410-b5e6-96231b3b80d8
to LLVM_LIBRARY_VISIBILITY and introduce LLVM_GLOBAL_VISIBILITY, which is
the opposite, for future use by dragonegg.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103495 91177308-0d34-0410-b5e6-96231b3b80d8
configured via --enable-doxygen. It seems some systems have broken pdfroff
so automatic use of it is not safe.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103217 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103213 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102977 91177308-0d34-0410-b5e6-96231b3b80d8
terminator instructions so that it applies to all terminators with
multiple successors, including invoke.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102909 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102479 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102399 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102140 91177308-0d34-0410-b5e6-96231b3b80d8
