| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Ord Unique can be a source of invisible, accidental
nondeterminism as explained in Note [No Ord for Unique].
This removes it, leaving a note with rationale.
It's unfortunate that I had to write Ord instances for
codegen data structures by hand, but I believe that it's a
right trade-off here.
Test Plan: ./validate
Reviewers: simonmar, austin, bgamari
Reviewed By: simonmar
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2370
GHC Trac Issues: #4012
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In #11555 we ended up generating references to the non-existence
stg_ap_0_upd. Here we add asserts to verify that we don't generate
references to non-existent selector or application symbols.
It would likely also make sense to add further asserts during code
generation, so we can catch the issue even closer to its source.
Test Plan: Validate
Reviewers: simonmar, austin, ezyang
Reviewed By: simonmar, austin
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2230
GHC Trac Issues: #11155
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This extends the previous work to revive the unregisterised GHC build
for AIX/ppc32. Strictly speaking, AIX runs on POWER4 (and later)
hardware, but the PPC32 instructions implemented in the PPC NCG
represent a compatible subset of the POWER4 ISA.
IBM AIX follows the PowerOpen ABI (and shares many similiarites with the
Linux PPC64 ELF V1 NCG backend) but uses the rather limited XCOFF
format (compared to ELF).
This doesn't support dynamic libraries yet.
A major limiting factor is that the AIX assembler does not support the
`@ha`/`@l` relocation types nor the ha16()/lo16() functions Darwin's
assembler supports. Therefore we need to avoid emitting those. In case
of numeric literals we simply compute the functions ourselves, while for
labels we have to use local TOCs and hope everything fits into a 16bit
offset (for ppc32 this gives us at most 16384 entries per TOC section,
which is enough to compile GHC).
Another issue is that XCOFF doesn't seem to have a relocation type for
label-differences, and therefore the label-differences placed into
tables-next-to-code can't be relocated, but the linker may rearrange
different sections, so we need to place all read-only sections into the
same `.text[PR]` section to workaround this.
Finally, the PowerOpen ABI distinguishes between function-descriptors
and actualy entry-point addresses. For AIX we need to be specific when
emitting assembler code whether we want the address of the function
descriptor `printf`) or for the entry-point (`.printf`). So we let the
asm pretty-printer prefix a dot to all emitted subroutine
calls (i.e. `BL`) on AIX only. For now, STG routines' entry-point labels
are not prefixed by a label and don't have any associated
function-descriptor.
Reviewers: austin, trommler, erikd, bgamari
Reviewed By: trommler, erikd, bgamari
Differential Revision: https://phabricator.haskell.org/D2019
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before the patch both Cmm and C symbols were declared
with 'EF_' macro:
#define EF_(f) extern StgFunPtr f()
but for Cmm symbols we know exact prototypes.
The patch splits there prototypes in to:
#define EFF_(f) void f() /* See Note [External function prototypes] */
#define EF_(f) StgFunPtr f(void)
Cmm functions are 'EF_' (External Functions),
C functions are 'EFF_' (External Foreign Functions).
While at it changed external C function prototype
to return 'void' to workaround ghc bug on m68k.
Described in detail in Trac #11395.
This makes simple tests work on m68k-linux target!
Thanks to Michael Karcher for awesome analysis
happening in Trac #11395.
Signed-off-by: Sergei Trofimovich <siarheit@google.com>
Test Plan: ran "hello world" on m68k successfully
Reviewers: simonmar, austin, bgamari
Reviewed By: bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1975
GHC Trac Issues: #11395
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In the past the canonical way for constructing an SDoc string literal was the
composition `ptext . sLit`. But for some time now we have function `text` that
does the same. Plus it has some rules that optimize its runtime behaviour.
This patch takes all uses of `ptext . sLit` in the compiler and replaces them
with calls to `text`. The main benefits of this patch are clener (shorter) code
and less dependencies between module, because many modules now do not need to
import `FastString`. I don't expect any performance benefits - we mostly use
SDocs to report errors and it seems there is little to be gained here.
Test Plan: ./validate
Reviewers: bgamari, austin, goldfire, hvr, alanz
Subscribers: goldfire, thomie, mpickering
Differential Revision: https://phabricator.haskell.org/D1784
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are currently 2 different ways to test for a static or dynamic
build:
* Test if WayDyn is in ways
* Test if Opt_Static is set
The problem is that these can easily go out of sync, especially when
using the
GHC API.
This commit replaces all queries of Opt_Static with an equivalent query
of
WayDyn. This would have prevented bug #8294 and fixes #11154.
Reviewers: hvr, austin, bgamari
Reviewed By: austin, bgamari
Differential Revision: https://phabricator.haskell.org/D1607
GHC Trac Issues: #10636
|
| |
|
|
|
|
|
|
| |
In order to accomplish this we need to ensure that emit DIEs for all
DebugBlocks, even those that have been optimized out, lest we end up
with undefined symbols of parents at link time.
Differential Revision: https://phabricator.haskell.org/D1279
|
| |
|
|
|
|
| |
Comes with Haddock submodule update.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Extend the PowerPC 32-bit native code generator for "64-bit
PowerPC ELF Application Binary Interface Supplement 1.9" by
Ian Lance Taylor and "Power Architecture 64-Bit ELF V2 ABI Specification --
OpenPOWER ABI for Linux Supplement" by IBM.
The latter ABI is mainly used on POWER7/7+ and POWER8
Linux systems running in little-endian mode. The code generator
supports both static and dynamic linking. PowerPC 64-bit
code for ELF ABI 1.9 and 2 is mostly position independent
anyway, and thus so is all the code emitted by the code
generator. In other words, -fPIC does not make a difference.
rts/stg/SMP.h support is implemented.
Following the spirit of the introductory comment in
PPC/CodeGen.hs, the rest of the code is a straightforward
extension of the 32-bit implementation.
Limitations:
* Code is generated only in the medium code model, which
is also gcc's default
* Local symbols are not accessed directly, which seems to
also be the case for 32-bit
* LLVM does not work, but this does not work on 32-bit either
* Must use the system runtime linker in GHCi, because the
GHC linker for "static" object files (rts/Linker.c) for
PPC 64-bit is not implemented. The system runtime
(dynamic) linker works.
* The handling of the system stack (register 1) is not ELF-
compliant so stack traces break. Instead of allocating a new
stack frame, spill code should use the "official" spill area
in the current stack frame and deallocation code should restore
the back chain
* DWARF support is missing
Fixes #9863
Test Plan: validate (on powerpc, too)
Reviewers: simonmar, trofi, erikd, austin
Reviewed By: trofi
Subscribers: bgamari, arnons1, kgardas, thomie
Differential Revision: https://phabricator.haskell.org/D629
GHC Trac Issues: #9863
|
| |
|
|
|
|
|
|
|
| |
The GranSim code was removed in dd56e9ab and 297b05a9 in 2009, and perhaps
other commits I couldn't find.
Reviewed By: austin
Differential Revision: https://phabricator.haskell.org/D737
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
I'm not really happy about perpetuating the hackish fix for #8696,
but at least in the context of building with -fhpc, the performance
cost should be negligible.
I'm suspicious about PlainModuleInitLabel and the Windows stuff too,
but I don't know what it does / can't test it (respectively) so I'll
leave those alone for now.
Hopefully out-of-process TH will save us from these hacks some day.
The test is an adaptation of T8696. It's a bit more awkward since
I couldn't think of a way to get cross-module tickbox references
without optimizations (inlining), but ghci doesn't permit -O for
some reason.
Test Plan: harbormaster; validate
Reviewers: austin
Reviewed By: austin
Subscribers: carter, thomie
Differential Revision: https://phabricator.haskell.org/D583
GHC Trac Issues: #9762
Conflicts:
testsuite/tests/ghci/scripts/all.T
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is where we actually make GHC emit DWARF code. The info section
contains all the general meta information bits as well as an entry for
every block of native code.
Notes:
* We need quite a few new labels in order to properly address starts
and ends of blocks.
* Thanks to Nathan Howell for taking the iniative to get our own Haskell
language ID for DWARF!
(From Phabricator D396)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
And fix things all the way down to it. Namely:
- remove 'r30' from free registers, it's an .LCTOC1 register
for gcc. generated .plt stubs expect it to be initialised.
- fix PicBase computation, which originally forgot to use 'tmp'
reg in 'initializePicBase_ppc.fetchPC'
- mark 'ForeighTarget's as implicitly using 'PicBase' register
(see comment for details)
- add 64-bit MO_Sub and test on alloclimit3/4 regtests
- fix dynamic label offsets to match with .LCTOC1 offset
Signed-off-by: Sergei Trofimovich <siarheit@google.com>
Test Plan: validate passes equal amount of vanilla/dyn tests
Reviewers: simonmar, erikd, austin
Reviewed By: erikd, austin
Subscribers: carter, thomie
Differential Revision: https://phabricator.haskell.org/D560
GHC Trac Issues: #8024, #9831
|
| |
|
|
| |
This reverts commit 3b5a840bba375c4c4c11ccfeb283f84c3a1ef22c.
|
| |
|
|
|
|
|
| |
This reverts commit 35672072b4091d6f0031417bc160c568f22d0469.
Conflicts:
compiler/main/DriverPipeline.hs
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In preparation for indirecting all references to closures,
we rename _closure to _static_closure to ensure any old code
will get an undefined symbol error. In order to reference
a closure foobar_closure (which is now undefined), you should instead
use STATIC_CLOSURE(foobar). For convenience, a number of these
old identifiers are macro'd.
Across C-- and C (Windows and otherwise), there were differing
conventions on whether or not foobar_closure or &foobar_closure
was the address of the closure. Now, all foobar_closure references
are addresses, and no & is necessary.
CHARLIKE/INTLIKE were not changed, simply alpha-renamed.
Part of remove HEAP_ALLOCED patch set (#8199)
Depends on D265
Signed-off-by: Edward Z. Yang <ezyang@mit.edu>
Test Plan: validate
Reviewers: simonmar, austin
Subscribers: simonmar, ezyang, carter, thomie
Differential Revision: https://phabricator.haskell.org/D267
GHC Trac Issues: #8199
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Previously, there were two variants of CLOSURE in C--:
- Top-level CLOSURE(foo_closure, foo, lits...), which defines a new
static closure and gives it a name, and
- Array CLOSURE(foo, lits...), which was used for the static char
and integer arrays.
They used the same name, were confusing, and didn't even generate
the correct internal label representation! So now, we have two
new forms:
- Top-level CLOSURE(foo, lits...) which automatically generates
foo_closure (along with foo_info, which we were doing already)
- Array ANONYMOUS_CLOSURE(foo, lits...) which doesn't generate
a foo_closure identifier.
Part of remove HEAP_ALLOCED patch set (#8199)
Signed-off-by: Edward Z. Yang <ezyang@mit.edu>
Test Plan: validate
Reviewers: simonmar, austin
Subscribers: simonmar, ezyang, carter, thomie
Differential Revision: https://phabricator.haskell.org/D264
GHC Trac Issues: #8199
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The commit fixes incorrect code generation of
integer-gmp package on ia64 due to C prototypes mismatch.
Before the patch prototypes for "foreign import prim" were:
StgWord poizh[];
After the patch they became:
StgFunPtr poizh();
Long story:
Consider the following simple example:
{-# LANGUAGE MagicHash, GHCForeignImportPrim, UnliftedFFITypes #-}
module M where
import GHC.Prim -- Int#
foreign import prim "poizh" poi# :: Int# -> Int#
Before the patch unregisterised build generated the
following 'poizh' reference:
EI_(poizh); /* StgWord poizh[]; */
FN_(M_poizh_entry) {
// ...
JMP_((W_)&poizh);
}
After the patch it looks this way:
EF_(poizh); /* StgFunPtr poizh(); */
FN_(M_poizh_entry) {
// ...
JMP_((W_)&poizh);
}
On ia64 it leads to different relocation types being generated:
incorrect one:
addl r14 = @ltoffx(poizh#)
ld8.mov r14 = [r14], poizh# ; r14 = address-of 'poizh#'
correct one:
addl r14 = @ltoff(@fptr(poizh#)), gp ; r14 = address-of-thunk 'poizh#'
ld8 r14 = [r14]
'@fptr(poizh#)' basically instructs assembler to creates
another obect consisting of real address to 'poizh' instructions
and module address. That '@fptr' object is used as a function "address"
This object is different for every module referencing 'poizh' symbol.
All indirect function calls expect '@fptr' object. That way
call site reads real destination address and set destination
module address in 'gp' register from '@fptr'.
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Previously, both Cabal and GHC defined the type PackageId, and we expected
them to be roughly equivalent (but represented differently). This refactoring
separates these two notions.
A package ID is a user-visible identifier; it's the thing you write in a
Cabal file, e.g. containers-0.9. The components of this ID are semantically
meaningful, and decompose into a package name and a package vrsion.
A package key is an opaque identifier used by GHC to generate linking symbols.
Presently, it just consists of a package name and a package version, but
pursuant to #9265 we are planning to extend it to record other information.
Within a single executable, it uniquely identifies a package. It is *not* an
InstalledPackageId, as the choice of a package key affects the ABI of a package
(whereas an InstalledPackageId is computed after compilation.) Cabal computes
a package key for the package and passes it to GHC using -package-name (now
*extremely* misnamed).
As an added bonus, we don't have to worry about shadowing anymore.
As a follow on, we should introduce -current-package-key having the same role as
-package-name, and deprecate the old flag. This commit is just renaming.
The haddock submodule needed to be updated.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Test Plan: validate
Reviewers: simonpj, simonmar, hvr, austin
Subscribers: simonmar, relrod, carter
Differential Revision: https://phabricator.haskell.org/D79
Conflicts:
compiler/main/HscTypes.lhs
compiler/main/Packages.lhs
utils/haddock
|
| |
|
|
|
|
| |
This enables GHC's PIC machinery for accessing tickboxes of other
packages correctly when building dynamic libraries. Previously
GHC was doing strange and wrong things in that situation. See #9012.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These array types are smaller than Array# and MutableArray# and are
faster when the array size is small, as they don't have the overhead
of a card table. Having no card table reduces the closure size with 2
words in the typical small array case and leads to less work when
updating or GC:ing the array.
Reduces both the runtime and memory allocation by 8.8% on my insert
benchmark for the HashMap type in the unordered-containers package,
which makes use of lots of small arrays. With tuned GC settings
(i.e. `+RTS -A6M`) the runtime reduction is 15%.
Fixes #8923.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The inline allocation version is 69% faster than the out-of-line
version, when cloning an array of 16 unit elements on a 64-bit
machine.
Comparing the new and the old primop implementations isn't
straightforward. The old version had a missing heap check that I
discovered during the development of the new version. Comparing the
old and the new version would requiring fixing the old version, which
in turn means reimplementing the equivalent of MAYBE_CG in StgCmmPrim.
The inline allocation threshold is configurable via
-fmax-inline-alloc-size which gives the maximum array size, in bytes,
to allocate inline. The size does not include the closure header size.
Allowing the same primop to be either inline or out-of-line has some
implication for how we lay out heap checks. We always place a heap
check around out-of-line primops, as they may allocate outside of our
knowledge. However, for the inline primops we only allow allocation
via the standard means (i.e. virtHp). Since the clone primops might be
either inline or out-of-line the heap check layout code now consults
shouldInlinePrimOp to know whether a primop will be inlined.
|
| |
|
|
|
|
|
| |
This results in a 57% runtime decrease when allocating an array of 128
bytes on a 64-bit machine.
Fixes #8876.
|
| | |
|
| |
|
|
|
|
|
| |
There's now an internal -dll-split flag, which we use to tell GHC how
the GHC package is split into 2 separate DLLs. This is used by
Packages.isDllName to determine whether a call is within the same
DLL, or whether it is a call to another DLL.
|
| |
|
|
| |
It doesn't actually use it yet
|
| |
|
|
|
|
|
|
|
| |
I'm not sure if we want to make this change permanently, but for now it
fixes the unreg build.
I've also removed some redundant special-case code that generated
prototypes for foreign functions. The standard pprTempAndExternDecls
now generates them.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* the new StgCmmArgRep module breaks a dependency cycle; I also
untabified it, but made no real changes
* updated the documentation in the wiki and change the user guide to
point there
* moved the allocation enters for ticky and CCS to after the heap check
* I left LDV where it was, which was before the heap check at least
once, since I have no idea what it is
* standardized all (active?) ticky alloc totals to bytes
* in order to avoid double counting StgCmmLayout.adjustHpBackwards
no longer bumps ALLOC_HEAP_ctr
* I resurrected the SLOW_CALL counters
* the new module StgCmmArgRep breaks cyclic dependency between
Layout and Ticky (which the SLOW_CALL counters cause)
* renamed them SLOW_CALL_fast_<pattern> and VERY_SLOW_CALL
* added ALLOC_RTS_ctr and _tot ticky counters
* eg allocation by Storage.c:allocate or a BUILD_PAP in stg_ap_*_info
* resurrected ticky counters for ALLOC_THK, ALLOC_PAP, and
ALLOC_PRIM
* added -ticky and -DTICKY_TICKY in ways.mk for debug ways
* added a ticky counter for total LNE entries
* new flags for ticky: -ticky-allocd -ticky-dyn-thunk -ticky-LNE
* all off by default
* -ticky-allocd: tracks allocation *of* closure in addition to
allocation *by* that closure
* -ticky-dyn-thunk tracks dynamic thunks as if they were functions
* -ticky-LNE tracks LNEs as if they were functions
* updated the ticky report format, including making the argument
categories (more?) accurate again
* the printed name for things in the report include the unique of
their ticky parent as well as if they are not top-level
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The main payload of this patch is to extend CPR so that it
detects when a function always returns a result constructed
with the *same* constructor, even if the constructor comes from
a sum type. This doesn't matter very often, but it does improve
some things (results below).
Binary sizes increase a little bit, I think because there are more
wrappers. This with -split-objs. Without split-ojbs binary sizes
increased by 6% even for HelloWorld.hs. It's hard to see exactly why,
but I think it was because System.Posix.Types.o got included in the
linked binary, whereas it didn't before.
Program Size Allocs Runtime Elapsed TotalMem
fluid +1.8% -0.3% 0.01 0.01 +0.0%
tak +2.2% -0.2% 0.02 0.02 +0.0%
ansi +1.7% -0.3% 0.00 0.00 +0.0%
cacheprof +1.6% -0.3% +0.6% +0.5% +1.4%
parstof +1.4% -4.4% 0.00 0.00 +0.0%
reptile +2.0% +0.3% 0.02 0.02 +0.0%
----------------------------------------------------------------------
Min +1.1% -4.4% -4.7% -4.7% -15.0%
Max +2.3% +0.3% +8.3% +9.4% +50.0%
Geometric Mean +1.9% -0.1% +0.6% +0.7% +0.3%
Other things in this commit
~~~~~~~~~~~~~~~~~~~~~~~~~~~
* Got rid of the Lattice class in Demand
* Refactored the way that products and newtypes are
decomposed (no change in functionality)
|
| |
|
|
|
| |
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 is a hopefully temporary measure until the new SRT design is
implemeented.
|
| | |
|
| |
|
|
|
|
| |
We need to make the SRT label external and unique when splitting,
because it is shared amongst all the functions in the module. Also
some SRT-related cleanup.
|
| | |
|
| | |
|
| |
|
|
|
| |
We can now get the Platform from the DynFlags inside an SDoc, so we
no longer need to pass the Platform in.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
And some knock-on changes
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\ |
|
| | | |
|
| | | |
|
