logical/sane approach to organizing all of the stuff that goes into writing out
DWARF information. Honestly? even this is too complex for what it's supposed to
be doing.

Trivia: It *looks* like there would be functionality changes, however there aren't!
llvm-svn: 71821

llvm-svn: 71819

Implement !if, analogous to $(if) in GNU make.

llvm-svn: 71815

llvm-svn: 71813

llvm-svn: 71812

Fix tests to not upset DejaGNU.

llvm-svn: 71811

Graduate LLVM to the big leagues by embedding a LISP processor into TableGen.

Ok, not really, but do support some common LISP functions:

* car
* cdr
* null

llvm-svn: 71805

Implement a !foreach operator analogous to GNU make's $(foreach).
Use it on dags and lists like this:

class decls {
  string name;
}

def Decls : decls;

class B<list<string> names> : A<!foreach(Decls.name, names, !strconcat(Decls.name, ", Sr."))>;

llvm-svn: 71803

Implement a !subst operation simmilar to $(subst) in GNU make to do
def/var/string substitution on generic pattern templates.  For example:

def Type;
def v4f32 : Type;
def TYPE : Type;

class GenType<Type t> {
  let type = !(subst TYPE, v4f32, t);
}

def TheType : GenType<TYPE>;

llvm-svn: 71801

llvm-svn: 71798

llvm-svn: 71796

llvm-svn: 71795

Implement !cast.

llvm-svn: 71794

Operation Enhancements

Create an OpInit class to serve as a base for all operation Inits.

Move parsing of operation constructs to separate functions and reference
from multiple places.

Add some commented out new operations.  Coming soon.

llvm-svn: 71789

Fix PR4207.

If we're resolving a list element access and we're given a VarInit,
return a new VarListElementInit referencing the VarInit.

llvm-svn: 71787

Part one of many.

llvm-svn: 71785

llvm-svn: 71784

adding another copy.

llvm-svn: 71783

- Reformatting.
- Use while() instead of do-while().
- Move simple constructors into .h file.

llvm-svn: 71782

llvm-svn: 71781

assertion is failing for some tests.

llvm-svn: 71779

llvm-svn: 71775

llvm-svn: 71771

to low-level sync operations.

The only one present at the moment is MemoryFence(), and only for the platforms
for which I could easily discern the proper way to do it.  If your favorite platform
isn't represented, patches are welcome!

llvm-svn: 71770

llvm-svn: 71769

llvm.eh.sjlj.* for better clarity as to their purpose and scope. Add
a description of llvm.eh.sjlj.setjmp to ExceptionHandling.html.
(llvm.eh.sjlj.longjmp documentation coming when that implementation is
added).

llvm-svn: 71758

asm construct into an assertion failure.

llvm-svn: 71757

Radar 6867696

llvm-svn: 71750

Basically, there was a situation where it was getting an empty vector and doing
a .back() on that. Which isn't cool.

llvm-svn: 71746

block with its unique predecessor.  Change the code to assert if that is not
the case, instead of trying to handle situations where the block has
multiple predecessors.

llvm-svn: 71744

of exception handling builtin sjlj targets in functions turns out not to 
be necessary. Marking the intrinsic implementation in the .td file as 
defining all registers is sufficient to get the context saved properly by 
the containing function.

llvm-svn: 71743

Dan was trying to catch the case where a basic block ends with a conditional
branch to the fall-through block.  In this case, all the instructions have
been moved out of FromBBI, leaving it empty.  It cannot end with a
conditional branch.  As the existing comment indicates, it will always fall
through to the next block.  If the block already had the next block (NBB)
listed as a successor, the preceding loop has a check for that and does not
remove it.  Thus, we need to check and add the successor only when it is
not already listed.

With Dan's change, the empty block often ends up with the fall-through
successor listed twice.  This exposed the problem in pr4195, where
CodePlacementOpt did not handle the same predecessor listed more than once.
It is also at least partially responsible for pr4202 and probably a similar
issue with Thumb branches being out of range.

llvm-svn: 71742

llvm-svn: 71741

llvm-svn: 71740

field name.  No functional changes.

llvm-svn: 71739

llvm-svn: 71738

llvm-svn: 71735

llvm-svn: 71734

llvm-svn: 71730

llvm-svn: 71726