stl_bvector.h are correctly included into *anything* that includes hash_map
or hash_set. ext/hash_map includes stl_vector.h directly and leaves
out the specializations, causing truly nasty bugs due to inconsistent
versions of vector<> being used for vector<bool> in different files.
llvm-svn: 7303
* Removed unused global and member variables
* Fixed comments (CodeGeneratorBug.cpp)
* Check for possibly failing GCC::create() and CBE::create()
* Remove generated files after diffing the output (e.g., shared object)
* Instead of using std::for_each, use explicit loops as std::for_each may
duplicate the functor, and ours carries state
* Changed member var from cl::opt<std::string> to just std::string
* Fixed doxygen comments
* Fixed string comparisons to use [ str.empty() ] instead of [ str == "" ]
* Cache instances of CBE and GCC in BugDriver across compilations and executions
while testing tools.
llvm-svn: 7302
Mangler.cpp: Constify parameter to makeNameProper, and use const_iterator.
Make Count an unsigned int, and use utostr().
Don't name parameters things that start with underscore.
Mangler.h: All of the above, and also: Add Emacs mode-line. Include <set>.
llvm-svn: 7301
The C backend is assumed correct and is used to generate shared objects to be
loaded by the other two code generators.
LLC debugging should be functional now, LLI needs a few more additions to work,
the major one is renaming of external functions to call the JIT lazy function
resolver.
Bugpoint now has a command-line switch -mode with options 'compile' and
'codegen' to debug appropriate portions of tools.
ExecutionDriver.cpp: Added implementations of AbstractInterpreter for LLC and
GCC, broke out common code within other tools, and added ability to generate C
code with CBE individually, without executing the program, and the GCC tool can
generate executables shared objects or executables.
If no reference output is specified to Bugpoint, it will be generated with CBE,
because it is already assumed to be correct for the purposes of debugging using
this method. As a result, many functions now accept as an optional parameter a
shared object to be loaded in, if specified.
llvm-svn: 7293
of codes. For example,
short kernel (short t1) {
t1 >>= 8; t1 <<= 8;
return t1;
}
became:
short %kernel(short %t1.1) {
%tmp.3 = shr short %t1.1, ubyte 8 ; <short> [#uses=1]
%tmp.5 = cast short %tmp.3 to int ; <int> [#uses=1]
%tmp.7 = shl int %tmp.5, ubyte 8 ; <int> [#uses=1]
%tmp.8 = cast int %tmp.7 to short ; <short> [#uses=1]
ret short %tmp.8
}
before, now it becomes:
short %kernel(short %t1.1) {
%tmp.3 = shr short %t1.1, ubyte 8 ; <short> [#uses=1]
%tmp.8 = shl short %tmp.3, ubyte 8 ; <short> [#uses=1]
ret short %tmp.8
}
which will become:
short %kernel(short %t1.1) {
%tmp.3 = and short %t1.1, 0xFF00
ret short %tmp.3
}
This implements cast-set.ll:test4 and test5
llvm-svn: 7290
doFinalization too except that would have made them shadow, not override,
the parent class :-P.
Allow *any* constant cast expression between pointers and longs,
or vice-versa, or any widening (not just same-size) conversion that
isLosslesslyConvertibleTo approves. This fixes oopack.
llvm-svn: 7288
