GitLab

Apparently some Clang 3.6 expects these to be sorted.

Patch due to Peter Wortmann.

Fixes #10687.

Summary:
This allows the code generator to give hints to later code generation
steps about which branch is most likely to be taken.  Right now it
is only taken into account in one place: a special case in
CmmContFlowOpt that swapped branches over to maximise the chance of
fallthrough, which is now disabled when there is a likelihood setting.

Test Plan: validate

Reviewers: austin, simonpj, bgamari, ezyang, tibbe

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D1273

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

When working on #10397, I noticed that "reorder" in
nativeCodeGen/seqBlocks took more than 60% of the time. With this
refactoring, it does not even show up in the profile any more. This
fixes #10422.

Differential Revision: https://phabricator.haskell.org/D893

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)

This generates DWARF, albeit indirectly using the assembler. This is
the easiest (and, apparently, quite standard) method of generating the
.debug_line DWARF section.

Notes:

* Note we have to make sure that .file directives appear correctly
  before the respective .loc. Right now we ppr them manually, which makes
  them absent from dumps. Fixing this would require .file to become a
  native instruction.

* We have to pass a lot of things around the native code generator. I
  know Ian did quite a bit of refactoring already, but having one common
  monad could *really* simplify things here...

* To support SplitObjcs, we need to emit/reset all DWARF data at every
  split. We use the occassion to move split marker generation to
  cmmNativeGenStream as well, so debug data extraction doesn't have to
  choke on it.

(From Phabricator D396)

The purpose of the Debug module is to collect all required information
to generate debug information (DWARF etc.) in the back-ends. Our main
data structure is the "debug block", which carries all information we have
about a block of code that is going to get produced.

Notes:

* Debug blocks are arranged into a tree according to tick scopes. This
  makes it easier to reason about inheritance rules. Note however that
  tick scopes are not guaranteed to form a tree, which requires us to
  "copy" ticks to not lose them.

* This is also where we decide what source location we regard as
  representing a code block the "best". The heuristic is basically that
  we want the most specific source reference that comes from the same file
  we are currently compiling. This seems to be the most useful choice in
  my experience.

* We are careful to not be too lazy so we don't end up breaking streaming.
  Debug data will be kept alive until the end of codegen, after all.

* We change native assembler dumps to happen right away for every Cmm group.
  This simplifies the code somewhat and is consistent with how pretty much
  all of GHC handles dumps with respect to streamed code.

(From Phabricator D169)

Fwiw, this wasn't really a proper .lhs to begin with...

I forget all the details, but I spent some time trying to
understand the current setup, and tried to simplify it a bit

Don't export `getUs` and `getUniqueUs`. `UniqSM` has a `MonadUnique` instance:

    instance MonadUnique UniqSM where
        getUniqueSupplyM = getUs
        getUniqueM  = getUniqueUs
        getUniquesM = getUniquesUs

Commandline-fu used:

    git grep -l 'getUs\>' |
        grep -v compiler/basicTypes/UniqSupply.lhs |
        xargs sed -i 's/getUs/getUniqueSupplyM/g

    git grep -l 'getUniqueUs\>' |
        grep -v combiler/basicTypes/UniqSupply.lhs |
        xargs sed -i 's/getUniqueUs/getUniqueM/g'

Follow up on b522d3a3

Reviewed By: austin, hvr

Differential Revision: https://phabricator.haskell.org/D220

Summary:
This includes pretty much all the changes needed to make `Applicative`
a superclass of `Monad` finally. There's mostly reshuffling in the
interests of avoid orphans and boot files, but luckily we can resolve
all of them, pretty much. The only catch was that
Alternative/MonadPlus also had to go into Prelude to avoid this.

As a result, we must update the hsc2hs and haddock submodules.
Signed-off-by: Austin Seipp <austin@well-typed.com>

Test Plan: Build things, they might not explode horribly.

Reviewers: hvr, simonmar

Subscribers: simonmar

Differential Revision: https://phabricator.haskell.org/D13

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

In some cases, the layout of the LANGUAGE/OPTIONS_GHC lines has been
reorganized, while following the convention, to

- place `{-# LANGUAGE #-}` pragmas at the top of the source file, before
  any `{-# OPTIONS_GHC #-}`-lines.

- Moreover, if the list of language extensions fit into a single
  `{-# LANGUAGE ... -#}`-line (shorter than 80 characters), keep it on one
  line. Otherwise split into `{-# LANGUAGE ... -#}`-lines for each
  individual language extension. In both cases, try to keep the
  enumeration alphabetically ordered.
  (The latter layout is preferable as it's more diff-friendly)

While at it, this also replaces obsolete `{-# OPTIONS ... #-}` pragma
occurences by `{-# OPTIONS_GHC ... #-}` pragmas.

Signed-off-by: Austin Seipp <austin@well-typed.com>

Authored-by: David Luposchainsky <dluposchainsky@gmail.com>
Signed-off-by: Austin Seipp <austin@well-typed.com>

This patch encompasses most of the basic infrastructure for GHCJS. It
includes:

  * A new extension, -XJavaScriptFFI
  * A new architecture, ArchJavaScript
  * Parser and lexer support for 'foreign import javascript', only
    available under -XJavaScriptFFI, using ArchJavaScript.
  * As a knock-on, there is also a new 'WayCustom' constructor in
    DynFlags, so clients of the GHC API can add custom 'tags' to their
    built files. This should be useful for other users as well.

The remaining changes are really just the resulting fallout, making sure
all the cases are handled appropriately for DynFlags and Platform.
Authored-by: Luite Stegeman <stegeman@gmail.com>
Signed-off-by: Austin Seipp <aseipp@pobox.com>

It doesn't actually use it yet

It now has its own class, and the addImport function is defined in that
class, rather than needing to be passed as an argument.

We have to reduce the maximum number of instructions to jump over depending on the number of info tables in a proc.

Its implementation is totally specific to PPC.

There were four bugs here.  Clearly I didn't test this enough to
expose the bugs - it appeared to work on x86/Linux, but completely by
accident it seems.

1. the delta was wrong by a factor of the slot size (as noted on #7498)

2. we weren't correctly aligning the stack pointer (sp needs to be
16-byte aligned on x86/x86_64)

3. we were doing the adjustment multiple times in the case of a block
that was both a return point and a local branch target.  To fix this I
had to add new shim blocks to adjust the stack pointer, and retarget
the original branches.  See comment for details.

4. we were doing the adjustment for CALL instructions, which is
unnecessary and wrong; only JMPs should be preceded by a stack
adjustment.

(Someone with a PPC box will need to update the PPC version of
allocMoreStack to fix the above bugs, using the x86 version as a
guide.)

Fixes #7498.

We don't yet have the slow path, for when we have to fall back to
separate compilation.

We also only currently handle the case qhere we're compiling Haskell
code with the NCG.

This patch adds more of the plumbing necessary to allow the nativeGen
to build multiple ways in a single compilation.

We were always passing 0 to cmmNativeGenStream, so now the 0 is just
hardcoded there.

This will make it a little more pleasant to have the nativegen
build for multiple ways at once.

This reverts the compiler parts of

    commit 7b594a5d
    Author: David Terei <davidterei@gmail.com>
    Date:   Mon Nov 21 12:05:18 2011 -0800

    Remove registerised code for dead architectures: mips, ia64, alpha,
    hppa1, m68k

In particular, we want to know whether bewareLoadStoreAlignment should
return True or False for them.

It also reverts

    commit 3fc68b5c
    Author: Simon Marlow <marlowsd@gmail.com>
    Date:   Wed Jan 4 11:44:02 2012 +0000

    Remove missing archs (mipseb, mipsel, alpha) (#5734)

    It doesn't hurt to map these to ArchUnknown since we don't need to
    know anything specific about them, and adding them would be a pain
    (there are a bunch of places where we have to case-match on all the
    arches to avoid warnings).

This removes the OldCmm data type and the CmmCvt pass that converts
new Cmm to OldCmm.  The backends (NCGs, LLVM and C) have all been
converted to consume new Cmm.

The main difference between the two data types is that conditional
branches in new Cmm have both true/false successors, whereas in OldCmm
the false case was a fallthrough.  To generate slightly better code we
occasionally need to invert a conditional to ensure that the
branch-not-taken becomes a fallthrough; this was previously done in
CmmCvt, and it is now done in CmmContFlowOpt.

We could go further and use the Hoopl Block representation for native
code, which would mean that we could use Hoopl's postorderDfs and
analyses for native code, but for now I've left it as is, using the
old ListGraph representation for native code.

All Cmm procedures now include the set of global registers that are live on
procedure entry, i.e., the global registers used to pass arguments to the
procedure. Only global registers that are use to pass arguments are included in
this list.

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