tblgen: In STVEBX: Intrinsic 'llvm.ppc.altivec.stvebx' expects 3 operands, not 2 operands!
instead of like this:
tblgen: In STVEBX: Intrinsic 'intrinsic_void expects 3 operands, not 2 operands!
llvm-svn: 27185
intrinsics that don't take pointer arguments now work. For example, we can
compile this:
int test3( __m128d *A) {
return _mm_movemask_pd(*A);
}
int test4( __m128 *A) {
return _mm_movemask_ps(*A);
}
to this:
_test3:
movl 4(%esp), %eax
movapd (%eax), %xmm0
movmskpd %xmm0, %eax
ret
_test4:
movl 4(%esp), %eax
movaps (%eax), %xmm0
movmskps %xmm0, %eax
ret
llvm-svn: 27090
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
from a dot file that is the output of DSA. Nodes to extract
are specified by giving the name of the node seen in the graphical
representation, i.e. in the .ps if the node is specified %xyz
asking for just x, xy, or xyz will retain it in the output file.
Because it operates on substrings underspecifying may result
in additional unexpected nodes. Be as specific as possible.
Obviously, however, if you ask for %xyz and there is a
getelementptr of %xyz you will get both nodes. Some manual
editing may still be necessary because of this, but this script
can pare down 10,000 line files to 20 line files, making like easier.
llvm-svn: 24851
if (!N.Val->hasOneUse()) {
std::map<SDOperand, SDOperand>::iterator CGMI = CodeGenMap.find(N);
if (CGMI != CodeGenMap.end()) return CGMI->second;
}
Suppose a DAG like this:
X
^ ^
/ \
USE1 USE2
Suppose USE1 is being selected first and during which X is selected and
returned a new node. After this, USE1 is no longer an use of X. During USE2
selection, X will be selected again since it has only one use!
The fix is to always query CodeGenMap.
llvm-svn: 24679
it has more than one real use (non-chain uses).
* Record folded chain producing node in CodeGenMap.
* Do not fold a chain producing node if it has already been selected as an
operand of a chain use.
llvm-svn: 24647
matching code that is not currently auto-generated by tblgen, e.g. X86
addressing mode. Selection routines for complex patterns can return multiple operands, e.g. X86 addressing mode returns 4.
llvm-svn: 24634
* Enhanced tblgen to handle instructions which have chain operand and writes a
chain result.
* Enhanced tblgen to handle instructions which produces no results. Part of
the change is a temporary hack which relies on instruction property (e.g.
isReturn, isBranch). The proper fix would be to change the .td syntax to
separate results dag from ops dag.
llvm-svn: 24587
def SHL8rCL : I<0xD2, MRM4r, (ops R8 :$dst, R8 :$src),
"shl{b} {%cl, $dst|$dst, %CL}",
[(set R8:$dst, (shl R8:$src, CL))]>, Imp<[CL],[]>;
This generates a CopyToReg operand and added its 2nd result to the shl as
a flag operand.
llvm-svn: 24557
of having to hack the nightly tester script itself.
as an example, I use the following for my machine:
$HOME/llvm/utils/NightlyTest.pl -parallel -release -enable-llcbeta \
-spec2000path /Volumes/ProjectsDisk/cvs/benchmarks/speccpu2000-llvm/benchspec/ \
-povraypath /Volumes/ProjectsDisk/cvs/benchmarks/povray31 \
-namdpath /Volumes/ProjectsDisk/cvs/benchmarks/namd
llvm-svn: 24136
write things like this:
def : Pat<(add GPRC:$in, 12),
(ADD12 GPRC:$in)>;
Andrew: if this isn't enough or doesn't work for you, please lemme know.
llvm-svn: 23819
a pattern match, make sure to emit the (minimal number of) type checks that
verify the pattern matches this specific instruction. This allows FMA32
patterns to not match double expressions for example.
llvm-svn: 23748
type constraint. This lets tblgen realize that it doesn't need any dynamic
type checks for fextend/fround on PPC (and many other targets), because there
are only two fp types.
llvm-svn: 23730
1. If an operation has to be int or fp and the target only supports one
int or fp type, relize that the op has to have that type.
2. If a target has operations on multiple types, do not emit matching code
for patterns involving those operators, since we do not emit the code to
check for them yet. This prevents PPC from generating FP ops currently.
Also move some code around into more logical places.
llvm-svn: 23724
doesn't have to specify them manually. It currently handles associativity,
e.g. knowing that (X*Y)+Z also matches X+(Y*Z) and will be extended in
the future.
It is smart enough to not introduce duplicate patterns or patterns that can
never match.
llvm-svn: 23526
Currently we check that immediate values live on the RHS of commutative
operators. Defining ORI like this, for example:
def ORI : DForm_4<24, (ops GPRC:$dst, GPRC:$src1, u16imm:$src2),
"ori $dst, $src1, $src2",
[(set GPRC:$dst, (or immZExt16:$src2, GPRC:$src1))]>;
results in:
tblgen: In ORI: Instruction can never match: Immediate values must be on the RHS of commutative operators!
llvm-svn: 23501
This does not check that types match yet, but PPC only has one integer type
;-).
This also doesn't have the code to build the resultant dag.
llvm-svn: 23414
constraints defined in the DAG node definitions in the .td files. This
allows us to infer (and check!) the types for all nodes in the current
ppc .td file. For example, instead of:
Inst pattern EQV: (set GPRC:i32:$rT, (xor (xor GPRC:i32:$rA, GPRC:i32:$rB), (imm)<<Predicate_immAllOnes>>))
we now fully infer:
Inst pattern EQV: (set:void GPRC:i32:$rT, (xor:i32 (xor:i32 GPRC:i32:$rA, GPRC:i32:$rB), (imm:i32)<<Predicate_immAllOnes>>))
from: (set GPRC:$rT, (not (xor GPRC:$rA, GPRC:$rB)))
llvm-svn: 23284
progress. It correctly parses instructions and pattern fragments and glues
together pattern fragments into instructions.
The only code it generates currently is some boilerplate code for things
like the EntryNode.
llvm-svn: 23261
These changes modify the makefiles so that the output of flex and bison are
placed in the SRC directory, not the OBJ directory. It is intended that they
be checked in as any other LLVM source so that platforms without convenient
access to flex/bison can be compiled. From now on, if you change a .y or
.l file you *must* also commit the generated .cpp and .h files.
llvm-svn: 23115
anonymous regclass definition renaming.
Change the generated code to emit register classes as properly namespace
qualified entities like everything else.
expose the actual class definition as an object, though this isn't quite
usable yet.
llvm-svn: 22920
instruction defined, actually emit this to the InstrInfoDescriptor, which
allows an assert in the machineinstrbuilder to do some checking for us,
and is required by the dag->dag emitter
llvm-svn: 22895
LLVM is able to merge identical static const globals, GCC isn't, and this caused
some bloat in the generated data. This has a marginal effect on PPC, shrinking
the implicit sets from 10->4, but shrinks X86 from 179 to 23, a much bigger
reduction.
This should speed up the register allocator as well by reducing the dcache
footprint for this static data.
llvm-svn: 22879
printed as part of the opcode. This allows something like
cmp${cc}ss in the x86 backed to be printed as cmpltss, cmpless, etc.
depending on what the value of $cc is.
llvm-svn: 22439
finished up, only resolve fully when the def is defined. This allows things
to be changed and all uses to be propagated through. This implements
TableGen/LazyChange.td and fixes TemplateArgRename.td in the process.
None of the .td files used in LLVM backends are changed at all by this
patch.
llvm-svn: 21344
differences, which means that identical instructions (after stripping off
the first literal string) do not run any different code at all. On the X86,
this turns this code:
switch (MI->getOpcode()) {
case X86::ADC32mi: printOperand(MI, 4, MVT::i32); break;
case X86::ADC32mi8: printOperand(MI, 4, MVT::i8); break;
case X86::ADC32mr: printOperand(MI, 4, MVT::i32); break;
case X86::ADD32mi: printOperand(MI, 4, MVT::i32); break;
case X86::ADD32mi8: printOperand(MI, 4, MVT::i8); break;
case X86::ADD32mr: printOperand(MI, 4, MVT::i32); break;
case X86::AND32mi: printOperand(MI, 4, MVT::i32); break;
case X86::AND32mi8: printOperand(MI, 4, MVT::i8); break;
case X86::AND32mr: printOperand(MI, 4, MVT::i32); break;
case X86::CMP32mi: printOperand(MI, 4, MVT::i32); break;
case X86::CMP32mr: printOperand(MI, 4, MVT::i32); break;
case X86::MOV32mi: printOperand(MI, 4, MVT::i32); break;
case X86::MOV32mr: printOperand(MI, 4, MVT::i32); break;
case X86::OR32mi: printOperand(MI, 4, MVT::i32); break;
case X86::OR32mi8: printOperand(MI, 4, MVT::i8); break;
case X86::OR32mr: printOperand(MI, 4, MVT::i32); break;
case X86::ROL32mi: printOperand(MI, 4, MVT::i8); break;
case X86::ROR32mi: printOperand(MI, 4, MVT::i8); break;
case X86::SAR32mi: printOperand(MI, 4, MVT::i8); break;
case X86::SBB32mi: printOperand(MI, 4, MVT::i32); break;
case X86::SBB32mi8: printOperand(MI, 4, MVT::i8); break;
case X86::SBB32mr: printOperand(MI, 4, MVT::i32); break;
case X86::SHL32mi: printOperand(MI, 4, MVT::i8); break;
case X86::SHLD32mrCL: printOperand(MI, 4, MVT::i32); break;
case X86::SHR32mi: printOperand(MI, 4, MVT::i8); break;
case X86::SHRD32mrCL: printOperand(MI, 4, MVT::i32); break;
case X86::SUB32mi: printOperand(MI, 4, MVT::i32); break;
case X86::SUB32mi8: printOperand(MI, 4, MVT::i8); break;
case X86::SUB32mr: printOperand(MI, 4, MVT::i32); break;
case X86::TEST32mi: printOperand(MI, 4, MVT::i32); break;
case X86::TEST32mr: printOperand(MI, 4, MVT::i32); break;
case X86::TEST8mi: printOperand(MI, 4, MVT::i8); break;
case X86::XCHG32mr: printOperand(MI, 4, MVT::i32); break;
case X86::XOR32mi: printOperand(MI, 4, MVT::i32); break;
case X86::XOR32mi8: printOperand(MI, 4, MVT::i8); break;
case X86::XOR32mr: printOperand(MI, 4, MVT::i32); break;
}
into this:
switch (MI->getOpcode()) {
case X86::ADC32mi:
case X86::ADC32mr:
case X86::ADD32mi:
case X86::ADD32mr:
case X86::AND32mi:
case X86::AND32mr:
case X86::CMP32mi:
case X86::CMP32mr:
case X86::MOV32mi:
case X86::MOV32mr:
case X86::OR32mi:
case X86::OR32mr:
case X86::SBB32mi:
case X86::SBB32mr:
case X86::SHLD32mrCL:
case X86::SHRD32mrCL:
case X86::SUB32mi:
case X86::SUB32mr:
case X86::TEST32mi:
case X86::TEST32mr:
case X86::XCHG32mr:
case X86::XOR32mi:
case X86::XOR32mr: printOperand(MI, 4, MVT::i32); break;
case X86::ADC32mi8:
case X86::ADD32mi8:
case X86::AND32mi8:
case X86::OR32mi8:
case X86::ROL32mi:
case X86::ROR32mi:
case X86::SAR32mi:
case X86::SBB32mi8:
case X86::SHL32mi:
case X86::SHR32mi:
case X86::SUB32mi8:
case X86::TEST8mi:
case X86::XOR32mi8: printOperand(MI, 4, MVT::i8); break;
}
After this, the generated asmwriters look pretty much as though they were
generated by hand. This shrinks the X86 asmwriter.inc files from 55101->39669
and 55429->39551 bytes each, and PPC from 16766->12859 bytes.
llvm-svn: 19760
strings starts out with a constant string, we emit the string first, using
a table lookup (instead of a switch statement).
Because this is usually the opcode portion of the asm string, the differences
between the instructions have now been greatly reduced. This allows many
more case statements to be grouped together.
This patch also allows instruction cases to be grouped together when the
instruction patterns are exactly identical (common after the opcode string
has been ripped off), and when the differing operand is a MachineInstr
operand that needs to be formatted.
The end result of this is a mean and lean generated AsmPrinter!
llvm-svn: 19759
emitting code like this:
case PPC::ADD: O << "add "; printOperand(MI, 0, MVT::i64); O << ", "; prin
tOperand(MI, 1, MVT::i64); O << ", "; printOperand(MI, 2, MVT::i64); O << '\n
'; break;
case PPC::ADDC: O << "addc "; printOperand(MI, 0, MVT::i64); O << ", "; pr
intOperand(MI, 1, MVT::i64); O << ", "; printOperand(MI, 2, MVT::i64); O << '
\n'; break;
case PPC::ADDE: O << "adde "; printOperand(MI, 0, MVT::i64); O << ", "; pr
intOperand(MI, 1, MVT::i64); O << ", "; printOperand(MI, 2, MVT::i64); O << '
\n'; break;
...
Emit code like this:
case PPC::ADD:
case PPC::ADDC:
case PPC::ADDE:
...
switch (MI->getOpcode()) {
case PPC::ADD: O << "add "; break;
case PPC::ADDC: O << "addc "; break;
case PPC::ADDE: O << "adde "; break;
...
}
printOperand(MI, 0, MVT::i64);
O << ", ";
printOperand(MI, 1, MVT::i64);
O << ", ";
printOperand(MI, 2, MVT::i64);
O << "\n";
break;
This shrinks the PPC asm writer from 24785->15205 bytes (even though the new
asmwriter has much more whitespace than the old one), and the X86 printers shrink
quite a bit too. The important implication of this is that GCC no longer hits swap
when building the PPC backend in optimized mode. Thus this fixes PR448.
-Chris
llvm-svn: 19755
and more understandable. It also allows us to do simple things like fold
consequtive literal strings together. For example, instead of emitting this
for the X86 backend:
O << "adc" << "l" << " ";
we now generate this:
O << "adcl ";
*whoa* :)
This shrinks the X86 asmwriters from 62729->58267 and 65176->58644 bytes
for the intel/att asm writers respectively.
llvm-svn: 19749
2. Fix a bug where the lib directory specified also had to be cwd
3. Weight the output so archive->archive edges are shorter
4. Generate two different graphs: one for libraries, one for objects.
5. Adjust the properties of the graphs till it looks nice.
llvm-svn: 19293
I've done some testing, and this seems to work, but if people who use
the nightly tester regularly could spot check these changes, I'd be
appreciative.
llvm-svn: 18464
* "dist" target now builds tar.gz, tar.bz2, and zip files suitable for
distribution. "dist" can only be run from $(BUILD_OBJ_ROOT) and implies
a "check".
* made the preconditions not do a recursive make and ensured that they are
executed sequentially.
* made the messages output by the makefile be prefixed with "llvm" and the
make level (e.g. llvm[1]: ) in the same way that make does so that the
messages are uniform and more readable.
* Fixed the tags target so that tags depends on TAGS which contains the
rules to build a file named TAGS
* Implemented the EXTRA_DIST feature in a few directories to make sure it
works.
llvm-svn: 17210
Chris Lattner