1. Check for Perl and only build llvm-config if its available.
2. Add some virtual components
3. Don't depend on "standard" location for Perl, but configured location
4. Document the tool with a POD file.
This version is now ready for testing by users.
llvm-svn: 27005
both input and output to render everything in C++, but that will be the
next patch. For now, it just runs nm and greps each .o or .a file for
the desired symbol.
llvm-svn: 27003
1. LLVMCBackend.o now depends on LLVMCodeGen.o (why we're not sure)
2. LLVMExecutionEngine.o no longer depends on LLVMInterpreter.o nor LLVMJIT.o
Thanks, Chris.
llvm-svn: 26976
is a handy tool for users of LLVM who want to be able to quickly get
information about LLVM's configuration. It is intended to be used in the
command line of other tools. Documentation will be forthcoming in a
subsequent patch.
llvm-svn: 26952
text enclosed in <tt>. This ensures that (a) the text is in a fixed width
font (to indicated generated text) and (b) the text wraps without causing
the page width to be extended. The main result of this is that the report
will wrap to conform to the window size in which it is displayed instead of
having a very wide length if a warning message is long.
llvm-svn: 26916
The instruction patterns do not contain enough information to resolve the
exact type of the destination if it of a generic vector type.
llvm-svn: 26892
makefile using the utils/GenLibDeps.pl script with the -flat option. It
records the dependencies between libraries in such a way that the
llvm-config script can easily read it (in makefile dependency format).
llvm-svn: 26876
the rule for building the LibDeps.txt file using GenLibDeps.pl. This needs
to be done from time to time manually in order to keep LibDeps.txt up to
date.
llvm-svn: 26875
determine the top directory. This allows the tool to find the correct top
directory when you have something like:
/x/llvm
/x/llvm2
/x/llvm3
Previously the scripts would always find /x/llvm even if you were in the
llvm2 or llvm3 directory because the pattern didn't allow the digits at
the end of the path.
llvm-svn: 26751
if (N1.getOpcode() == ISD::ADD &&
...)
if (... &&
(N1.getNumOperands() == 1 || !isNonImmUse(N1.Val, N10.Val))) &&
...)
TableGen knows N1 must have more than one operand.
llvm-svn: 26592
compilation, C++ compilation, and linker options.
e.g. This is the options I use for testing on my x86 iMac:
nice ./NightlyTest.pl -release -cflags "-Os -DNDEBUG -fomit-frame-pointer" -cxxflags "-Os -DNDEBUG -finline-functions -felide-constructors -fomit-frame-pointer"
llvm-svn: 26057
us to avoid creating lots of "Operand" types with different printers, instead
we can fold several together and use modifiers. For example, we can now use:
${target:call} to say that the operand should be printed like a 'call' operand.
llvm-svn: 26024
due to ordering issue. i.e. they were selected for chain use first.
Now at load select time, check if it is being selected for a chain use and if
it has only a single real use. If so, return a HANDLENODE (with the load as
its operand) in its place and record it.
When it is folded or the load is selected for a real use, the isel records it
as the replacement for the HANDLENODE. The replacement is done when all nodes
are selected.
This scheme exposed a couple of problems where cycles can happen. (See comments
in EmitMatchCode() for descriptions of the problems and their workaround /
solutions.) These problems have been resolved with a small compile time
penality.
llvm-svn: 25995
Chain is initially set to the chain operand of store node, when it reaches
load, if it matches the load then Chain is set to the chain operand of the
load.
However, if the matching code that follows this fails, isel moves on to the
next pattern but it does not restore Chain to the chain operand of the store.
So when it tries to match the next store / op / load pattern it would fail on
the Chain == load.getOperand(0) test.
The solution is for each chain operand to get a unique name. e.g. Chain10.
llvm-svn: 25931
if (N1.getOpcode() == ISD::LOAD &&
N1.hasOneUse() &&
!CodeGenMap.count(N1.getValue(0)) &&
!CodeGenMap.count(N1.getValue(1))) {
instead of this:
if (N1.getOpcode() == ISD::LOAD) {
if (N1.hasOneUse()) {
if (!CodeGenMap.count(N1.getValue(0))) {
if (!CodeGenMap.count(N1.getValue(1))) {
llvm-svn: 25763
"if" statements (indenting it appropriately, of course) instead of using goto's.
This inverts the logic for all of the if statements, which makes things simpler
to understand in addition to making the generated code easier to read.
llvm-svn: 25757
directly to the output file. This makes things simple because the code doesn't
have to worry about indentation or the case when there is no goto. It also
allows us to indent the code better without touching everything :)
llvm-svn: 25756
If store's chain operand is load, then use load's chain operand instead. If
it isn't (likely a TokenFactor), then do not allow the folding.
llvm-svn: 25708
get the order, don't compute it ourselves.
Don't emit stuff like (14<<0), emit 14 instead.
Don't attempt to get target properties for builtin instructions.
llvm-svn: 25672
has already been selected. The number of use check is not strong enough since
a node can be replaced with newly created target node. e.g. If the original
node has two uses, when it is selected for one of the uses it is replaced with
another. Each node now has a single use but isel still should not fold it.
llvm-svn: 25651
instruction to produce a result. e.g MUL8m, the instruction does not
produce a explicit result. However it produces an implicit result in
AL which would be copied to a temp. The root operator of the matching
pattern is a mul so the use would expect it to produce a result.
llvm-svn: 25458
SNDPOutFlag to DAG nodes. These properties do not belong to target specific
instructions.
* Added DAG node property SNDPOptInFlag. It's same as SNDPInFlag except it's
optional. Used by ret / call, etc.
llvm-svn: 25154
SDOperand Tmp0,Tmp1,Tmp2,Tmp3,;
GCC has a bug (24907) in which is fails to catch this, but VC++ correctly
notes its illegality, so tblgen must be taught to only generate legal C++.
llvm-svn: 25075
Currently tblgen cannot tell which operands in the operand list are results so
it assumes the first one is a result. This is bad. Ideally we would fix this
by separating results from inputs, e.g. (res R32:$dst),
(ops R32:$src1, R32:$src2). But that's a more distruptive change. Adding
'let noResults = 1' is the workaround to tell tblgen that the instruction does
not produces a result. It works for now since tblgen does not support
instructions which produce multiple results.
llvm-svn: 25017
use too much stack space, overflowing the stack for large functions. Instead
of emitting new SDOperands in each match block, we emit some common ones at
the top of SelectCode then reuse them when possible.
This reduces the stack size of SelectCode from 28K to 21K. Note that GCC
compiles it to 512 bytes :-/
I've filed GCC PR 25505 to track this.
llvm-svn: 24882
it keeps it from trying to add the same node to the node set
over and over if it matches multiple given patterns. Also in cases where there
are a lot of patterns to be matched, and it matches an early one, this
will make the script run slightly faster. It's more there because it logically
should be, than anything else, I mean, Python is never going to be fast ;-)
llvm-svn: 24876
