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
