the generation of the procdef's asmsymbols
o also removed unnecessary definition of procdef alias symbols for Darwin
(they are already defined in ncgutil.alloc_proc_symbol)
git-svn-id: trunk@42341 -
private_extern (or plain global in case of PECOFF, as the effect is
the same there): visible across object files, but they become local
when linked into a binary/library. This enables cross-unit inlining
of functions accessig implementation-only symbols.
git-svn-id: trunk@42340 -
a_load_const/reg_subsetref() (needed for handling 32 bit platforms using a purely
high level code generator like LLVM's, and may also improve the situation for
16 bit platforms)
o can probably be optimized to split them into parts that cover partial word loads
and complete word loads (to reduce useless merging)
git-svn-id: trunk@42165 -
var-parameter, as the size sometimes gets changed in this routine and
high level code generators don't use the location.size but the def
git-svn-id: trunk@40633 -
hlcgllvm in the uses clause of every unit that calls create_hlcodegen
o prevents dependency cycles that can cause llvm codegen units to init
before the cpu variants, which is bad since the llvm versions have to
override the cpu variants in their init code (+ added checks in the
init code that they are in fact initialised later)
git-svn-id: branches/debug_eh@40410 -
(needed for LLVM, where we need two copies of the finally code: one in case
an exception occurs, and one in case none is raised)
o also first finalize parameters and only then code generator temps, since
in theory the former could create more of the latter
git-svn-id: trunk@40345 -
so that they can still be freed after the reference has been changed
(e.g. in case of array indexing or record field accesses) (mantis #33628)
git-svn-id: trunk@38814 -
code from one unit to another, but in splitting some methods
I made a couple of mistakes :/ (causing global variables to be
initialised three times)
git-svn-id: trunk@35461 -
o separate information for reading and writing, because e.g. in a
try-block, only the writes to local variables and parameters are
volatile (they have to be committed immediately in case the next
instruction causes an exception)
o for now, only references to absolute memory addresses are marked
as volatile
o the volatily information is (should be) properly maintained throughout
all code generators for all archictures with this patch
o no optimizers or other compiler infrastructure uses the volatility
information yet
o this functionality is not (yet) exposed at the language level, it
is only for internal code generator use right now
git-svn-id: trunk@34996 -
