Make insertFarJumpAtAddr() return void, because nothing uses its return value.
Remove some commented-out code.
Implement replaceMachineCodeForFunction() for SPARC.
llvm-svn: 9203
Rename SlotCalculator::getValSlot() to SlotCalculator::getSlot(),
SlotCalculator::insertValue() to SlotCalculator::getOrCreateSlot(),
SlotCalculator::insertVal() to SlotCalculator::insertValue(), and
SlotCalculator::doInsertVal() to SlotCalculator::doInsertValue().
llvm-svn: 9190
* Move the constructors from .h file here
* Document ExecutionEngine::create()
* Catch exception possibly thrown by ModuleProvider::releaseModule()
llvm-svn: 9181
They are already marked precious in llvm/Makefile.rules, and removing
this line seems to fix the Makefile so that the Yacc output is placed
into the object tree and not the source tree.
llvm-svn: 9179
LLVM.
Added information on how to use the autoconf code to specify LLVM's
location and setup separate source and object trees.
Fixed some of the wording to be more accurate, especially regarding the
building of libraries.
Added information on where built files are placed.
Added a link to the llvmdev mailing list so that they can ask us questions.
llvm-svn: 9173
For now, we translate linkonce into weak linkage in the bytecode format because
we don't have enough bits to represent it. We will rev the bytecode version
soon anyways, so this will be fixed in the near future.
llvm-svn: 9170
this list (except use_size()) are constant time. Before the killUse method
(used whenever something stopped using a value) was linear time, and thus
very very slow for large programs.
This speeds GCCAS up _substantially_ on large programs: almost 2x for 176.gcc:
176.gcc: 77.07s -> 37.38s
177.mesa: 7.59s -> 5.57s
252.eon: 21.02s -> 19.52s (*)
253.perlbmk: 11.40s -> 13.05s
254.gap: 7.25s -> 7.42s
252.eon would speed up a whole lot more, but optimization time is being
dominated by the inlining pass, which needs to be fixed.
llvm-svn: 9160
this list (except use_size()) are constant time. Before the killUse method
(used whenever something stopped using a value) was linear time, and thus
very very slow for large programs.
This speeds GCCAS up _substantially_ on large programs: almost 2x for 176.gcc:
176.gcc: 77.07s -> 37.38s
177.mesa: 7.59s -> 5.57s
252.eon: 21.02s -> 19.52s (*)
253.perlbmk: 11.40s -> 13.05s
254.gap: 7.25s -> 7.42s
252.eon would speed up a whole lot more, but optimization time is being
dominated by the inlining pass, which needs to be fixed.
llvm-svn: 9159
John Criswell