possible before resorting to pextrw and pinsrw.
- Better codegen for v4i32 shuffles masquerading as v8i16 or v16i8 shuffles.
- Improves (i16 extract_vector_element 0) codegen by recognizing
(i32 extract_vector_element 0) does not require a pextrw.
llvm-svn: 44836
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
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
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
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
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
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
Chris Lattner