| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
| |
We were being inconsistent about how we tested whether dump flags
were enabled; in particular, sometimes we also checked the verbosity,
and sometimes we didn't.
This lead to oddities such as "ghc -v4" printing an "Asm code" section
which didn't contain any code, and "-v4" enabled some parts of
"-ddump-deriv" but not others.
Now all the tests use dopt, which also takes the verbosity into account
as appropriate.
|
|
|
|
|
| |
Mostly d -> g (matching DynFlag -> GeneralFlag).
Also renamed if* to when*, matching the Haskell if/when names
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The main change here is that the Cmm parser now allows high-level cmm
code with argument-passing and function calls. For example:
foo ( gcptr a, bits32 b )
{
if (b > 0) {
// we can make tail calls passing arguments:
jump stg_ap_0_fast(a);
}
return (x,y);
}
More details on the new cmm syntax are in Note [Syntax of .cmm files]
in CmmParse.y.
The old syntax is still more-or-less supported for those occasional
code fragments that really need to explicitly manipulate the stack.
However there are a couple of differences: it is now obligatory to
give a list of live GlobalRegs on every jump, e.g.
jump %ENTRY_CODE(Sp(0)) [R1];
Again, more details in Note [Syntax of .cmm files].
I have rewritten most of the .cmm files in the RTS into the new
syntax, except for AutoApply.cmm which is generated by the genapply
program: this file could be generated in the new syntax instead and
would probably be better off for it, but I ran out of enthusiasm.
Some other changes in this batch:
- The PrimOp calling convention is gone, primops now use the ordinary
NativeNodeCall convention. This means that primops and "foreign
import prim" code must be written in high-level cmm, but they can
now take more than 10 arguments.
- CmmSink now does constant-folding (should fix #7219)
- .cmm files now go through the cmmPipeline, and as a result we
generate better code in many cases. All the object files generated
for the RTS .cmm files are now smaller. Performance should be
better too, but I haven't measured it yet.
- RET_DYN frames are removed from the RTS, lots of code goes away
- we now have some more canned GC points to cover unboxed-tuples with
2-4 pointers, which will reduce code size a little.
|
|\ |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This squashes the "out of spill slots" panic that occasionally happens
on x86, by adding instructions to bump and retreat the C stack pointer
as necessary. The panic has become more common since the new codegen,
because we lump code into larger blocks, and the register allocator
isn't very good at reusing stack slots for spilling (see Note [extra
spill slots]).
|
| | |
|
| |
| |
| |
| | |
I assume that this is what is intended, as it is used with foldl'
|
| | |
|
|/ |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Also moved the type definition into RegAlloc.Linear.State to de-orphan
the Monad instance.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
HaskellMachRegs.h is no longer included in anything under compiler/
Also, includes/CodeGen.Platform.hs now includes "stg/MachRegs.h"
rather than <stg/MachRegs.h> which means that we always get the file
from the tree, rather than from the bootstrapping compiler.
|
| |
|
| |
|
| |
|
|
|
|
| |
No functional differences yet
|
| |
|
|
|
|
|
|
|
|
| |
There was a long-standing ToDo here that I just did: if a real
register is clobbered by the current instruction, then we should move
it to another free register rather than spilling it to memory. This
case crops up more often now that the register allocator can allocate
into the fixed Rn registers.
|
|
|
|
|
|
|
|
|
| |
Proc-point splitting is only required by backends that do not support
having proc-points within a code block (that is, everything except the
native backend, i.e. LLVM and C).
Not doing proc-point splitting saves some compilation time, and might
produce slightly better code in some cases.
|
|
|
|
|
| |
We didn't trip over this one until I started generating code without
proc-point splitting, which has more join points and loops.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was made possible by the recent change to codeGen to attach the
live GlobalRegs to every CmmJump, and we'll be relying on it quite
heavily in the new code generator too.
What this means essentially is that when we see
x = R1
the register allocator will automatically assign x to R1 and generate
no code at all (also known as "coalescing"). It wasn't possible before
because the register allocator had to assume that R1 was always live,
because it didn't have access to accurate liveness information.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
We can now get the Platform from the DynFlags inside an SDoc, so we
no longer need to pass the Platform in.
|
| |
|
|
|
|
|
|
|
| |
This patch enhances Platform's ArchARM to include ARM ABI value. It also
tweaks configure machinery to detect hard-float ABI and to set it wherever
needed. Finally when hard-float ABI is in use, pass appropriate compiler
option to the LLVM's llc. Fixes #5914.
|
| |
|
|
|
|
| |
hppa1, m68k
|
|
|
|
|
| |
We only use it for "compiler" sources, i.e. not for libraries.
Many modules have a -fno-warn-tabs kludge for now.
|
| |
|
| |
|
|
|
|
|
|
|
| |
This reverts commit 2dea11a442e1d14d86fa661804de06a721943bf0.
On second thoughts, this does make sense, for unregisterised via-C
arches at least.
|
|
|
|
|
|
|
| |
It doesn't make sense. If platformArch is ArchUnknown then we don't know
the answer to any questions about the arch. So now if we don't recognise
the arch we just fail, and the new arch will need to be added to the
datatype.
|
|
|
|
| |
And some knock-on changes
|
| |
|
|
|
|
|
| |
CmmTop -> CmmDecl
CmmPgm -> CmmGroup
|
|
|
|
|
|
|
| |
This patch enhances ArchARM with ARM ISA and ISA extensions details
as is suggested in the comment in Platform.hs file. The patch is needed
by future patch which will use ARM ISA information in order to pass
appropriate command-line option to the LLVM llc tool.
|