per-function collector model. Collector is now the factory for
CollectorMetadata, so the latter may be subclassed.

llvm-svn: 44827

llvm-svn: 44826

don't have to #include config.h in it.  #including config.h breaks
other projects that have their own autoconf stuff and try to #include
the llvm headers.  One obscure example is llvm-gcc.

llvm-svn: 44825

Thompson. Usage should be something like this:

open Llvm
open Llvm_bitreader

match read_bitcode_file fn with
  | Bitreader_failure msg ->
      prerr_endline msg
  | Bitreader_success m -> 
      ...;
      dispose_module m

Compile with: ocamlc llvm.cma llvm_bitreader.cma
              ocamlopt llvm.cmxa llvm_bitreader.cmxa

llvm-svn: 44824

Explicitly set the string literal type from "char *" to "constant array of char".

At this point, I am fairly certain the front-end is correct. Unfortunately, the back-end is still unhappy.

That said, I've commented out the two lines in globalinit.c that are causing problems.

Chris, please have a look...thanks!

llvm-svn: 44823

between fetching the size of the expression map (for use as
the next integer id for an Expr*) and the creation of the
entry in the map could be non-deterministic.  This could
cause the size of the map to be incremented prior to the
index being determine.

On Linux the map entry would be created first, causing the
map to the "size" to be incremented prior to it being
queried. On Mac OS X we had the reverse behavior. Now the
size is always queried prior to the new id being inserted
into the map.

This was the real cause of the bit-overrun triggered in
PR 1847:

  http://llvm.org/bugs/show_bug.cgi?id=1847
  
Also reverted the change in patch 44813, which was a bogus
fix to this problem:

  http://llvm.org/viewvc/llvm-project?rev=44813&view=rev

llvm-svn: 44822

compiles again on Linux.

llvm-svn: 44821

llvm-svn: 44820

llvm-svn: 44819

Use it for Darwin.

llvm-svn: 44818

Reimplement the xform in Analysis/ConstantFolding.cpp where we can use
targetdata to validate that it is safe.  While I'm in there, fix some const
correctness issues and generalize the interface to the "operand folder".

llvm-svn: 44817

Add support for initializing char arrays from string literals.

Adapted from a patch by Anders Carlsson.

llvm-svn: 44816

out-of-bounds bit accesses.  The checks are only performed
in a Debug build.

llvm-svn: 44815

llvm-svn: 44814

dataflow analysis over expressions and decls.

This should fix bug 1847:

http://llvm.org/bugs/show_bug.cgi?id=1847

Thanks to Török Edwin for providing a test case that
identified the problem.

llvm-svn: 44813

llvm-svn: 44810

type.

llvm-svn: 44809

llvm-svn: 44808

llvm-svn: 44807

llvm-svn: 44806

llvm-svn: 44805

llvm-svn: 44804

These should probably be something like:

  CFI(".cfi_def_cfa_offset 16\n")

where CFI is defined to a noop on darwin and other platforms
that don't support those directives.

llvm-svn: 44803

on functions as it calculates them.

llvm-svn: 44802

llvm-svn: 44801

llvm-svn: 44800

llvm-svn: 44799

llvm-svn: 44798

llvm-svn: 44797

using the minimum possible number of bytes.  For little
endian targets run on little endian machines, apints are
stored in memory from LSB to MSB as before.  For big endian
targets on big endian machines they are stored from MSB to
LSB which wasn't always the case before (if the target and
host endianness doesn't match values are stored according
to the host's endianness).  Doing this requires knowing the
endianness of the host, which is determined when configuring -
thanks go to Anton for this.  Only having access to little
endian machines I was unable to properly test the big endian
part, which is also the most complicated...

llvm-svn: 44796

llvm-svn: 44795

All bad stuff from SSE version is implicitely inherited :)

llvm-svn: 44794

broken, because doesn't mark xmm regs properly

llvm-svn: 44793

This will allow us (theoretically) to unwind through JITer.
The code wasn't verified, so I'm pretty sure offsets are wrong :)

llvm-svn: 44792

get it to compile.

llvm-svn: 44791

llvm-svn: 44790

llvm-svn: 44789

llvm-svn: 44788

llvm-svn: 44787

how the CodeGen machinery works.

llvm-svn: 44786