This makes the parser much easier to understand, eliminates a ton of global variables,
and gives tblgen nice caret diagnostics.  It is also faster, but tblgen probably doesn't
care about performance.

There are a couple of FIXMEs which I will take care of next.

llvm-svn: 44274

llvm-svn: 44264

I added the lexing files to the VStudio projects and removed the .l files from the 
VStudio projects.  There was a problem with use of strtoll in TGLexer.cpp and Chris
suggested switching to strtol, so that's included here.

Additionally, this checkin adds minimal x64 builds to the VStudio builds.  Build issues
related to x64 in the windows specific files for DynamicLibrary.inc and Singals.inc
are worked around, but not ultimately solved.  Binaries used to be stored in

...\win32\{Debug|Release}

but are now kept in

...\win32\bin\{win32|x64}\{Debug|Release}

intermediate files will continue to be stored in the individual project directories under 
win32.  

Some names will likely change in the future to reflect that the vstudio projects
are no longer 32-bit only, but I wanted to get things up and running today so kept away
from bigger restructuring.

llvm-svn: 44260

llvm-svn: 44257

llvm-svn: 44227

llvm-svn: 44226

llvm-svn: 44212

llvm-svn: 44211

one dependency on flex and gets rid of two ".cvs" files.

llvm-svn: 44210

in favour of teaching CCAssignToStack that size 0 and/or align
0 means to use the ABI values.  This seems a neater solution.
It is safe since no legal value type has size 0.

llvm-svn: 44107

to use different mappings for EH and debug info;
no functional change yet.
Fix warning in X86CodeEmitter.

llvm-svn: 44056

llvm-svn: 44031

llvm-svn: 44030

Target maintainers: please check that the instructions for your target are correctly marked.

llvm-svn: 44012

llvm-svn: 44001

This makes DwarfRegNum to accept list of numbers instead.
Added three different "flavours", but only slightly tested on x86-32/linux.
Please check another subtargets if possible,

llvm-svn: 43997

llvm-svn: 43993

dealing with types whose size & alignment are
different on different subtargets.  Use it for x86 f80.

llvm-svn: 43988

llvm-svn: 43971

llvm-svn: 43929

Much improvement in exception handling.

llvm-svn: 43794

Restore an assertion that arithmetic can be performed on this format.

llvm-svn: 43638

the one that takes an operand list instead of explicit
operands.  There is one left though, the more interesting
one :)

llvm-svn: 43290

llvm-svn: 43182

llvm-svn: 43126

llvm-svn: 43095

llvm-svn: 43094

Silenced some VC warnings.

I'm getting linker errors, though: unresolved externals:

llvm::Split<class llvm::BasicBlock *,struct llvm::GraphTraits<class llvm::BasicBlock *> >(class llvm::DominatorTreeBase<class llvm::BasicBlock> &,class llvm::BasicBlock *)

and

llvm::Split<struct llvm::Inverse<class llvm::BasicBlock *>,struct llvm::GraphTraits<struct llvm::Inverse<class llvm::BasicBlock *> > >(class llvm::DominatorTreeBase<class llvm::BasicBlock> &,class llvm::BasicBlock *)

Where are these defined?

llvm-svn: 43073

take a deleted nodes vector, instead of requiring it.

One more significant change:  Implement the start of a legalizer that
just works on types.  This legalizer is designed to run before the 
operation legalizer and ensure just that the input dag is transformed
into an output dag whose operand and result types are all legal, even
if the operations on those types are not.

This design/impl has the following advantages:

1. When finished, this will *significantly* reduce the amount of code in
   LegalizeDAG.cpp.  It will remove all the code related to promotion and
   expansion as well as splitting and scalarizing vectors.
2. The new code is very simple, idiomatic, and modular: unlike 
   LegalizeDAG.cpp, it has no 3000 line long functions. :)
3. The implementation is completely iterative instead of recursive, good
   for hacking on large dags without blowing out your stack.
4. The implementation updates nodes in place when possible instead of 
   deallocating and reallocating the entire graph that points to some 
   mutated node.
5. The code nicely separates out handling of operations with invalid 
   results from operations with invalid operands, making some cases
   simpler and easier to understand.
6. The new -debug-only=legalize-types option is very very handy :), 
   allowing you to easily understand what legalize types is doing.

This is not yet done.  Until the ifdef added to SelectionDAGISel.cpp is
enabled, this does nothing.  However, this code is sufficient to legalize
all of the code in 186.crafty, olden and freebench on an x86 machine.  The
biggest issues are:

1. Vectors aren't implemented at all yet
2. SoftFP is a mess, I need to talk to Evan about it.
3. No lowering to libcalls is implemented yet.
4. Various operations are missing etc.
5. There are FIXME's for stuff I hax0r'd out, like softfp.

Hey, at least it is a step in the right direction :).  If you'd like to help,
just enable the #ifdef in SelectionDAGISel.cpp and compile code with it.  If
this explodes it will tell you what needs to be implemented.  Help is 
certainly appreciated.

Once this goes in, we can do three things:

1. Add a new pass of dag combine between the "type legalizer" and "operation
   legalizer" passes.  This will let us catch some long-standing isel issues
   that we miss because operation legalization often obfuscates the dag with
   target-specific nodes.
2. We can rip out all of the type legalization code from LegalizeDAG.cpp,
   making it much smaller and simpler.  When that happens we can then 
   reimplement the core functionality left in it in a much more efficient and
   non-recursive way.
3. Once the whole legalizer is non-recursive, we can implement whole-function
   selectiondags maybe...

llvm-svn: 42981

llvm-svn: 42896

If the user did not check out LLVM and request it to be built, it should be a build error. This relies on the user having a successful build of LLVM, but the tests will fail if they dont. 

llvm-svn: 42514

llvm-svn: 42423

llvm-svn: 42282

between two registers in the specific class.

llvm-svn: 42123

llvm-svn: 42069

llvm-svn: 42036

are strict about such things.

llvm-svn: 41956

1.
[(set GR32:$dst, (add GR32:$src1, GR32:$src2)),
 (modify EFLAGS)]
This indicates the source pattern expects the instruction would produce 2 values. The first is the result of the addition. The second is an implicit definition in register EFLAGS.
2.
def : Pat<(parallel (addc GR32:$src1, GR32:$src2), (modify EFLAGS)), ()>
Similar to #1 except this is used for def : Pat patterns.

llvm-svn: 41897

llvm-svn: 41861

llvm-svn: 41849