| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- nativeGen/Instruction defines a type class for a generic
instruction set. Each of the instruction sets we have,
X86, PPC and SPARC are instances of it.
- The register alloctors use this type class when they need
info about a certain register or instruction, such as
regUsage, mkSpillInstr, mkJumpInstr, patchRegs..
- nativeGen/Platform defines some data types enumerating
the architectures and operating systems supported by the
native code generator.
- DynFlags now keeps track of the current build platform, and
the PositionIndependentCode module uses this to decide what
to do instead of relying of #ifdefs.
- It's not totally retargetable yet. Some info info about the
build target is still hardwired, but I've tried to contain
most of it to a single module, TargetRegs.
- Moved the SPILL and RELOAD instructions into LiveInstr.
- Reg and RegClass now have their own modules, and are shared
across all architectures.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We used to generated things like:
extern StgWordArray (newCAF) __attribute__((aligned (8)));
((void (*)(void *))(W_)&newCAF)((void *)R1.w);
(which is to say, pretend that newCAF is some data, then cast it to a
function and call it).
This goes wrong on at least IA64, where:
A function pointer on the ia64 does not point to the first byte of
code. Intsead, it points to a structure that describes the function.
The first quadword in the structure is the address of the first byte
of code
so we end up dereferencing function pointers one time too many, and
segfaulting.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This merge does not turn on the new codegen (which only compiles
a select few programs at this point),
but it does introduce some changes to the old code generator.
The high bits:
1. The Rep Swamp patch is finally here.
The highlight is that the representation of types at the
machine level has changed.
Consequently, this patch contains updates across several back ends.
2. The new Stg -> Cmm path is here, although it appears to have a
fair number of bugs lurking.
3. Many improvements along the CmmCPSZ path, including:
o stack layout
o some code for infotables, half of which is right and half wrong
o proc-point splitting
|
| | |
|
| | |
|
| |
|
|
| |
Modules that need it import it themselves instead.
|
| |
|
|
|
|
|
|
|
| |
The type parameter to a C-- procedure now represents a control-flow
graph, not a single instruction. The newtype ListGraph preserves the
current representation while enabling other representations and a
sensible way of prettyprinting. Except for a few changes in the
prettyprinter the new compiler binary should be bit-for-bit identical
to the old.
|
| | |
|
| |
|
|
|
|
|
| |
Older GHCs can't parse OPTIONS_GHC.
This also changes the URL referenced for the -w options from
WorkingConventions#Warnings to CodingStyle#Warnings for the compiler
modules.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of attaching the information whether a Label is going to be
accessed dynamically or not (distinction between IdLabel/DynLabel and
additional flags in ModuleInitLabel and PlainModuleInitLabel), we hand
dflags through the CmmOpt monad and the NatM monad. Before calling
labelDynamic in PositionIndependentCode, we extract thisPackage from
dflags and supply the current package to labelDynamic, so it can take
this information into account instead of extracting it from the labels
itself. This simplifies a lot of code in codeGen that just hands
through this_pkg.
|
| |
|
|
| |
for 64 bit archs.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The problem of the splitter was that it re-emitted section directives
for every dynamic label found. The following was torn apart
.symbol_stubs
.indirect <symbol>
L_<symbol>$stub:
jmp *...
L_<symbol>$stub_binder:
..somebinding code..
into
.symbol_stubs
.indirect_symbol <symbol>
L_<symbol>$stub:
jmp *...
.symbol_stubs <--- NEW
L_<symbol>$stub_binder:
..somebinding code..
This is incorrect as the Mac OS assembler enforces that every new code
section that goes into .symbol_stubs is associated with the linker
directive .indirect_symbol. This sanity check is obviously violated
when we reemit .symbol_stub in the splitter. The solution is to ignore
everything that ends with $stub_binder as new label, and chuck it into
a single label for $stub.
Also the splitter has to recognize .section __DATA... for the lazy_ptr
indirection symbol. Adds a reminder to PositionIndependentCode.hs to
take care of the splitter when the code generation is changed.
This should not affect -fvia-c as the code generated by the C compiler
is entirely different.
|
| | |
|
| |
|
|
| |
A recent patch accidentally had x86_TARGET_ARCH instead of i386_TARGET_ARCH.
|
| |
|
|
|
|
|
|
|
|
|
| |
In i386 position-independent symbol stubs, the NCG used to print
jmp %edx
instead of
jmp *%edx
Apple's assembler used to silently accept this, but has recently started to print warnings about it.
MERGE TO STABLE.
|
| |
|
|
|
|
|
| |
Continue repairing breakage from patch
"x86_64: support PIC and therefore, Mac OS X in the NCG",
this time something affecting (linux && !i386)
|
| |
|
|
| |
Make things compile on Linux again
|
| |
|
|
|
|
|
|
|
|
| |
Supporting x86_64-apple-darwin in the NCG basically boils down to supporting
position-independent code in the NCG.
PIC code works almost exactly the same as on x86_64-linux, while position-dependent
code is not supported at all.
This patch implements -fPIC for x86_64-linux, too, but that is untested.
|
| |
|
|
|
|
|
|
| |
We can't use lazy binding for tail-calls accross shared libraries, because dyld
will crash due to incorrect stack layout. We can't get the stack alignment right for
both cross-library tailcalls and foreign calls, so we have to bypass the stub code altogether
and load the address to branch to from the non-lazy pointer table.
|
|
|
Most of the other users of the fptools build system have migrated to
Cabal, and with the move to darcs we can now flatten the source tree
without losing history, so here goes.
The main change is that the ghc/ subdir is gone, and most of what it
contained is now at the top level. The build system now makes no
pretense at being multi-project, it is just the GHC build system.
No doubt this will break many things, and there will be a period of
instability while we fix the dependencies. A straightforward build
should work, but I haven't yet fixed binary/source distributions.
Changes to the Building Guide will follow, too.
|
