Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add small primitive types, like `Int8#`/`Word8#` #74

Merged
merged 7 commits into from Mar 1, 2018

Conversation

Projects
None yet
9 participants
@michalt
Copy link
Contributor

commented Sep 26, 2017

The proposal has been accepted; the following discussion is mostly of historic interest.


Rendered

michalt added some commits Sep 24, 2017

Write proposal for new small primitives
Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com>
Update pull request link for "small primitives" proposal
Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com>
@jared-w

This comment has been minimized.

Copy link

commented Sep 26, 2017

Is there any reason for stopping the primitives at 32 instead of going all the way up to 64?

(or even 128, 256, 512? The latest SIMD magic out there works as high as 512 now, after all, and there is hardware out there that uses higher than 64 bits natively for certain things.)

@bgamari

This comment has been minimized.

Copy link
Contributor

commented Sep 26, 2017

Is there any reason for stopping the primitives at 32 instead of going all the way up to 64?

This brings up a great point: Note that on 32-bit machines Int64# and Word64# already exist; the same applies to {Int,Word}32 on 64-bit machines. However, annoyingly, these aren't always available, leading to a lot of annoying conditionals in the implementation of the compiler and libraries. It would be great to fix this. See #11953.

@michalt

This comment has been minimized.

Copy link
Contributor Author

commented Sep 27, 2017

@jared-w @bgamari Sure, that sounds reasonable - I'll extend the proposal to also add Int64#/Word64#. (thanks for the Trac link! I totally forgot about this)
Regarding SIMD: GHC seems to already have the ability to represent vectors (see VecRep PrimRep). I'm not sure how well it's supported though. In any case, SIMD probably deserves a separate discussion.

Expand the "small primitives" proposal with Int64#/Word64#
Suggested by @jared-w and @bgamari

Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com>
@andrewthad

This comment has been minimized.

Copy link
Contributor

commented Oct 3, 2017

I'm strongly +1 on this. One additional motivation that the proposal doesn't mention is that this would improve the state of things for SIMD operations. See the Int/Word Size Wrinkle discussion in the GHC Wiki page for SIMD design. On a related note, we currently have functions like this in ghc-prim:

unpackInt8X16# :: Int8X16# -> (# Int#, Int#, Int#, Int#, Int#, Int#, Int#, Int#, Int#, Int#, Int#, Int#, Int#, Int#, Int#, Int# #)

Notice that on a 64-bit platform, the result type takes up 8 times as much space as it really needs to. It would be nice to instead have:

unpackInt8X16# :: Int8X16# -> (# Int8#, Int8#, Int8#, Int8#, Int8#, Int8#, Int8#, Int8#, Int8#, Int8#, Int8#, Int8#, Int8#, Int8#, Int8#, Int8# #)

I don't think changes like this should be a part of the proposal though. I'm fine with just having the primitives, but it's nice that it will pave the way for future improvements to SIMD as well.

@cartazio

This comment has been minimized.

Copy link

commented Oct 3, 2017

@andrewthad

This comment has been minimized.

Copy link
Contributor

commented Oct 10, 2017

The proposal discusses unpacking these into data types, but something I don't see addressed is what the calling conventions for functions that take sub-word-size primitives as arguments looks like. For example:

f :: Int8# -> Int16# -> Int8# -> Int32# -> Foo

On a 64-bit platform, it's conceivable that the codegen could turn this, when fully applied, into something that take a single machine word as an argument. I'm not sure if your proposal is suggesting doing this or not.

@michalt

This comment has been minimized.

Copy link
Contributor Author

commented Oct 11, 2017

@andrewthad Good point! I haven't actually thought much about it yet, but it's probably better to discuss this here than over diffs/IRC.

First of all, this proposal definitely does not propose to pack things into registers when calling/jumping. So in your example I'd still expect we would pass each argument separately. But now the question becomes: how exactly should we pass them in registers.

I couldn't find all that much information about the current calling convention (the trac page basically says: "the first N argumements in registers and the rest on the stack"). Is there some NOTE somewhere? If not, pointers to code would be appreciated. :)

In any case, on x86-64 every register has a 8/16/32 bit version, so it should be relatively easy to use the current rule. On x86-32 things get more tricky since not every register exposes the lower 8/16 bits. So we might need to change the rule to something like “for each argument take the first register of the right width that isn't used yet, if none remain use stack for remaining ones”.

Alternatively, I’m wondering if we could initially still represent things at full register width (64-/32-bit) and only do sign-/zero-extend (narrow) when loading (storing) from (to) heap or stack. There’s probably something that would make this difficult ;) Also, not sure about the performance impact.

I don't know much about other architectures GHC supports, so please chime in if you know more. :)

@bgamari

This comment has been minimized.

Copy link
Contributor

commented Oct 11, 2017

Is there some NOTE somewhere? If not, pointers to code would be appreciated. :)

Off hand I can't think of any Note that's immediately relevant. However, do look at compiler/cmm/CmmCallConv.hs for the logic that determines GHC's calling convention.

@michalt

This comment has been minimized.

Copy link
Contributor Author

commented Oct 15, 2017

@bgamari: Lol, how did I miss that!? ;) Thanks!

Anyway, I've had a look at the code and also at LLVM:

  • At the point of CmmCallConv we're only concerned with register numbers (which is nicely arch agnostic).

  • GHC's calling convention in LLVM will simply expand everything to the native register width (X86CallingConv.td):

    On x86-32:

      // Promote i8/i16 arguments to i32.
      CCIfType<[i8, i16], CCPromoteToType<i32>>,
    

    On x86-64:

      // Promote i8/i16/i32 arguments to i64.
      CCIfType<[i8, i16, i32], CCPromoteToType<i64>>,
    

So for this proposal, I'd just follow the approach in LLVM, i.e., use the current convention and zero-extend to the native register width. AFAICS this means that LLVM backend should "just work" without any changes. I don't know enough about native backend(s) to know whether they'll need some changes (they do have some awareness of different register width, e.g., nativeGen/Format, so maybe things will mostly just work?)

What do you think? (Please shout if I missed something!)

@nomeata

This comment has been minimized.

Copy link
Contributor

commented Nov 10, 2017

What is the status of this proposal?

Add a note about calling convention to "small primitives" proposal
Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com>
@michalt

This comment has been minimized.

Copy link
Contributor Author

commented Nov 15, 2017

@nomeata I've updated the proposal with a note about the calling convention. So unless there are more questions/concerns, I think this proposal is ready to be reviewed.

@simonmar

This comment has been minimized.

Copy link

commented Nov 16, 2017

(sorry for the delay, just got around to taking a look at this)

This needs to happen, the only reason we didn't do this earlier was that we sneakily avoided needing real sized integral types by adding the narrow primops so that we could implement all of Data.Int and Data.Word using Int# and Word#. Once we have real sized types, we could reimplement Data.Int and Data.Word using sized primops and kill the narrow primops. (I realise this isn't part of this proposal, but it's a nice cleanup).

For the calling conventions my guess is that we don't want to require zero-extension or sign-extension, just declare the unused bits to be undefined. I believe this is what the C ABI does.

@michalt

This comment has been minimized.

Copy link
Contributor Author

commented Nov 16, 2017

@simonmar Thanks for having a look! Regarding the calling convention - I think you're right. We should declare the top bits unused/unspecified. On the Cmm level, we'll need to do the zero-extend/truncate, but that should be just an implementation detail. I'll update the proposal.

Also, I've started to prototype this using Int8# as an example. Here's the current state if anyone is interested: ghc/ghc@master...michalt:subword-primops (so far seems to work on x86-64 :)
If the proposal gets accepted, I'll upload it to Phab so we can discuss any implementation details (before implementing the remaining primops)

michalt added some commits Nov 16, 2017

small primitives proposal: corrections about calling conventions
Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com>
small primitives proposal: update motivation
Based on suggestions from @simonmar

Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com>
@simonmar

This comment has been minimized.

Copy link

commented Nov 20, 2017

On the Cmm level, we'll need to do the zero-extend/truncate, but that should be just an implementation detail

Could you elaborate on why we need that? It's not obvious to me.

@michalt

This comment has been minimized.

Copy link
Contributor Author

commented Nov 22, 2017

@simonmar So far I've run into:

  • Cmm type system doesn't like assigning a value with width of 8-bits to the global register, which is 64- or 32-bits (cmm-lint fails). We could probably relax this.
  • But that would likely need some changes LLVM backend due to similar type-system related reasons.
  • More than that, in 32-bit x86, lowering to assembly would be harder since not all registers have corresponding 8-bit ones (e.g., for %eax we can use %al, but %edi doesn't have a corresponding 8-bit register). This gets problematic due to calling convention. We could probably work this around by going through another register, e.g., move the 8-bit value to %al and then move it again from %eax to %edi (the upper bits might be garbage, but we wouldn't care).

All of this seems a bit hacky and more error prone, so for now I'm zero-extending/truncating everything on Cmm level (MO_UU_Conv) and everything else mostly just works.

But I'm definitely open to suggestions :) (maybe I'm doing something silly and there's an easier way?)

@cartazio

This comment has been minimized.

Copy link

commented Nov 22, 2017

@simonmar

This comment has been minimized.

Copy link

commented Nov 23, 2017

@michalt Yeah, I don't have any better suggestions. The situation is already quite delicate on 32-bit x86 since we do sometimes need to do 8-bit operations (readInt8OffAddr# for example) and I think the way things are set up we can just about be sure that we only do these with registers that have 8-bit verisons. There might be a comment about this somewhere.

So all our 8-bit primops are actually going to be implemented as word-sized operations? Somehow that makes me a bit sad, but maybe it's OK.

@michalt

This comment has been minimized.

Copy link
Contributor Author

commented Nov 23, 2017

@simonmar Oh, I meant that the extend/truncate would happen only when calling Cmm functions/continuations. If we have a sequence of primops on the proposed Int8#, they would actually use the 8-bit registers (e.g., %al) and operations (e.g., addb). Only at a call site, we would extend them (and the callee would have to truncate them). My current prototype does this in MkGraph.{copyIn,copyOutOflow}, which seem to be the functions taking care of moving the parameters in/out to/from where they are expected.
Does this explanation help? Would you prefer it if I uploaded the prototype to Phab (as a WIP diff) to discuss this?

@michalt

This comment has been minimized.

Copy link
Contributor Author

commented Dec 4, 2017

@nomeata @simonmar I don't see any major open questions, so I think this is ready for review. (please do let me know if I missed something :)

@andrewthad

This comment has been minimized.

Copy link
Contributor

commented Dec 7, 2017

I just realized that this proposal doesn't specify the RuntimeRep for these new types:

data RuntimeRep = VecRep VecCount VecElem   -- ^ a SIMD vector type
                | TupleRep [RuntimeRep]     -- ^ An unboxed tuple of the given reps
                | SumRep [RuntimeRep]       -- ^ An unboxed sum of the given reps
                | LiftedRep       -- ^ lifted; represented by a pointer
                | UnliftedRep     -- ^ unlifted; represented by a pointer
                | IntRep          -- ^ signed, word-sized value
                | WordRep         -- ^ unsigned, word-sized value
                | Int64Rep        -- ^ signed, 64-bit value (on 32-bit only)
                | Word64Rep       -- ^ unsigned, 64-bit value (on 32-bit only)
                | AddrRep         -- ^ A pointer, but /not/ to a Haskell value
                | FloatRep        -- ^ a 32-bit floating point number
                | DoubleRep       -- ^ a 64-bit floating point number

Do they all have IntRep and WordRep, or does RuntimeRep need to be given additional data constructors as well?

@cartazio

This comment has been minimized.

Copy link

commented Dec 7, 2017

@michalt

This comment has been minimized.

Copy link
Contributor Author

commented Dec 12, 2017

@andrewthad Yes, I think RuntimeRep should get a new constructor for each new primitive type (similarly to PrimRep).

@nomeata

This comment has been minimized.

Copy link
Contributor

commented Dec 12, 2017

@andrewthad Yes, I think RuntimeRep should get a new constructor for each new primitive type (similarly to PrimRep).

Will you add that to the proposal?

@Ericson2314

This comment has been minimized.

Copy link

commented Dec 12, 2017

I'm tempted to advocate for

| IntRep (Maybe Int)
| WordRep (Maybe Int)
| FloatRep Int
@andrewthad

This comment has been minimized.

Copy link
Contributor

commented Dec 12, 2017

@Ericson2314 If we were going to go that route, I would prefer something closer to what is done for SIMD vector types:

data ByteCount = ByteCountNative | ByteCount1 | ByteCount2 | ByteCount4 | ByteCount8

data RuntimeRep =
  ...
  | IntRep ByteCount
  | WordRep ByteCount
  ...
@cartazio

This comment has been minimized.

Copy link

commented Dec 13, 2017

small-primitives: add extending `RuntimeRep` to implementation plan
Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com>
@michalt

This comment has been minimized.

Copy link
Contributor Author

commented Feb 5, 2018

@nomeata Added! (sorry for the delay!)

@nomeata

This comment has been minimized.

Copy link
Contributor

commented Feb 5, 2018

Now ready for review, or do you anticipate further changes/discussion here?

@michalt

This comment has been minimized.

Copy link
Contributor Author

commented Feb 7, 2018

@nomeata I think it's ready. :)

@nomeata nomeata merged commit a2b3b56 into ghc-proposals:master Mar 1, 2018

nomeata added a commit that referenced this pull request Mar 1, 2018

michalt added a commit to michalt/ghc that referenced this pull request Mar 6, 2018

RFC: Add Int8# and Word8#
This is the first step of implementing:
ghc-proposals/ghc-proposals#74

The main highlights/changes:

- `primops.txt.pp` gets two new sections for two new primitive types
  for signed and unsigned 8-bit integers (`Int8#` and `Word8`
  respectively) along with basic arithmetic and comparison
  operations. `PrimRep`/`RuntimeRep` get two new constructors for
  them. All of the primops translate into the existing `MachOP`s.

- For `CmmCall`s the codegen will now zero-extend the values at call
  site (so that they can be moved to the right register) and then
  truncate them back their original width.

- x86 native codegen needed some updates, since it wasn't able to deal
  with the new widths, but all the changes are quite localized. LLVM
  backend seems to just work.

Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com>

michalt added a commit to michalt/ghc that referenced this pull request Mar 6, 2018

RFC: Add Int8# and Word8#
Summary:
This is the first step of implementing:
ghc-proposals/ghc-proposals#74

The main highlights/changes:

- `primops.txt.pp` gets two new sections for two new primitive types
  for signed and unsigned 8-bit integers (`Int8#` and `Word8`
  respectively) along with basic arithmetic and comparison
  operations. `PrimRep`/`RuntimeRep` get two new constructors for
  them. All of the primops translate into the existing `MachOP`s.

- For `CmmCall`s the codegen will now zero-extend the values at call
  site (so that they can be moved to the right register) and then
  truncate them back their original width.

- x86 native codegen needed some updates, since it wasn't able to deal
  with the new widths, but all the changes are quite localized. LLVM
  backend seems to just work.

Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com>

Test Plan: ./validate with new tests

Reviewers: hvr, goldfire, bgamari, simonmar

Subscribers: rwbarton, thomie, carter

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

michalt added a commit to michalt/ghc that referenced this pull request May 6, 2018

RFC: Add Int8# and Word8#
Summary:
This is the first step of implementing:
ghc-proposals/ghc-proposals#74

The main highlights/changes:

- `primops.txt.pp` gets two new sections for two new primitive types
  for signed and unsigned 8-bit integers (`Int8#` and `Word8`
  respectively) along with basic arithmetic and comparison
  operations. `PrimRep`/`RuntimeRep` get two new constructors for
  them. All of the primops translate into the existing `MachOP`s.

- For `CmmCall`s the codegen will now zero-extend the values at call
  site (so that they can be moved to the right register) and then
  truncate them back their original width.

- x86 native codegen needed some updates, since it wasn't able to deal
  with the new widths, but all the changes are quite localized. LLVM
  backend seems to just work.

Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com>

Test Plan: ./validate with new tests

Reviewers: hvr, goldfire, bgamari, simonmar

Subscribers: rwbarton, thomie, carter

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

michalt added a commit to michalt/ghc that referenced this pull request Aug 5, 2018

RFC: Add Int8# and Word8#
Summary:
This is the first step of implementing:
ghc-proposals/ghc-proposals#74

The main highlights/changes:

- `primops.txt.pp` gets two new sections for two new primitive types
  for signed and unsigned 8-bit integers (`Int8#` and `Word8`
  respectively) along with basic arithmetic and comparison
  operations. `PrimRep`/`RuntimeRep` get two new constructors for
  them. All of the primops translate into the existing `MachOP`s.

- For `CmmCall`s the codegen will now zero-extend the values at call
  site (so that they can be moved to the right register) and then
  truncate them back their original width.

- x86 native codegen needed some updates, since it wasn't able to deal
  with the new widths, but all the changes are quite localized. LLVM
  backend seems to just work.

Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com>

Test Plan: ./validate with new tests

Reviewers: hvr, goldfire, bgamari, simonmar

Subscribers: rwbarton, thomie, carter

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

Abhiroop added a commit to Abhiroop/ghc-1 that referenced this pull request Aug 9, 2018

RFC: Add Int8# and Word8#
Summary:
This is the first step of implementing:
ghc-proposals/ghc-proposals#74

The main highlights/changes:

- `primops.txt.pp` gets two new sections for two new primitive types
  for signed and unsigned 8-bit integers (`Int8#` and `Word8`
  respectively) along with basic arithmetic and comparison
  operations. `PrimRep`/`RuntimeRep` get two new constructors for
  them. All of the primops translate into the existing `MachOP`s.

- For `CmmCall`s the codegen will now zero-extend the values at call
  site (so that they can be moved to the right register) and then
  truncate them back their original width.

- x86 native codegen needed some updates, since it wasn't able to deal
  with the new widths, but all the changes are quite localized. LLVM
  backend seems to just work.

Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com>

Test Plan: ./validate with new tests

Reviewers: hvr, goldfire, bgamari, simonmar

Subscribers: rwbarton, thomie, carter

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

Abhiroop added a commit to Abhiroop/ghc-1 that referenced this pull request Aug 13, 2018

RFC: Add Int8# and Word8#
Summary:
This is the first step of implementing:
ghc-proposals/ghc-proposals#74

The main highlights/changes:

- `primops.txt.pp` gets two new sections for two new primitive types
  for signed and unsigned 8-bit integers (`Int8#` and `Word8`
  respectively) along with basic arithmetic and comparison
  operations. `PrimRep`/`RuntimeRep` get two new constructors for
  them. All of the primops translate into the existing `MachOP`s.

- For `CmmCall`s the codegen will now zero-extend the values at call
  site (so that they can be moved to the right register) and then
  truncate them back their original width.

- x86 native codegen needed some updates, since it wasn't able to deal
  with the new widths, but all the changes are quite localized. LLVM
  backend seems to just work.

Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com>

Test Plan: ./validate with new tests

Reviewers: hvr, goldfire, bgamari, simonmar

Subscribers: rwbarton, thomie, carter

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

bgamari added a commit to bgamari/ghc that referenced this pull request Oct 4, 2018

Add Int8# and Word8#
This is the first step of implementing:
ghc-proposals/ghc-proposals#74

The main highlights/changes:

- `primops.txt.pp` gets two new sections for two new primitive types
  for signed and unsigned 8-bit integers (`Int8#` and `Word8`
  respectively) along with basic arithmetic and comparison
  operations. `PrimRep`/`RuntimeRep` get two new constructors for
  them. All of the primops translate into the existing `MachOP`s.

- For `CmmCall`s the codegen will now zero-extend the values at call
  site (so that they can be moved to the right register) and then
  truncate them back their original width.

- x86 native codegen needed some updates, since it wasn't able to deal
  with the new widths, but all the changes are quite localized. LLVM
  backend seems to just work.

Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com>

Test Plan: ./validate with new tests

Reviewers: hvr, goldfire, bgamari, simonmar

Subscribers: Abhiroop, dfeuer, rwbarton, thomie, carter

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

bgamari added a commit to bgamari/ghc that referenced this pull request Oct 4, 2018

Add Int8# and Word8#
This is the first step of implementing:
ghc-proposals/ghc-proposals#74

The main highlights/changes:

- `primops.txt.pp` gets two new sections for two new primitive types
  for signed and unsigned 8-bit integers (`Int8#` and `Word8`
  respectively) along with basic arithmetic and comparison
  operations. `PrimRep`/`RuntimeRep` get two new constructors for
  them. All of the primops translate into the existing `MachOP`s.

- For `CmmCall`s the codegen will now zero-extend the values at call
  site (so that they can be moved to the right register) and then
  truncate them back their original width.

- x86 native codegen needed some updates, since it wasn't able to deal
  with the new widths, but all the changes are quite localized. LLVM
  backend seems to just work.

Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com>

Test Plan: ./validate with new tests

Reviewers: hvr, goldfire, bgamari, simonmar

Subscribers: Abhiroop, dfeuer, rwbarton, thomie, carter

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

bgamari added a commit to bgamari/ghc that referenced this pull request Oct 5, 2018

Add Int8# and Word8#
This is the first step of implementing:
ghc-proposals/ghc-proposals#74

The main highlights/changes:

- `primops.txt.pp` gets two new sections for two new primitive types
  for signed and unsigned 8-bit integers (`Int8#` and `Word8`
  respectively) along with basic arithmetic and comparison
  operations. `PrimRep`/`RuntimeRep` get two new constructors for
  them. All of the primops translate into the existing `MachOP`s.

- For `CmmCall`s the codegen will now zero-extend the values at call
  site (so that they can be moved to the right register) and then
  truncate them back their original width.

- x86 native codegen needed some updates, since it wasn't able to deal
  with the new widths, but all the changes are quite localized. LLVM
  backend seems to just work.

Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com>

Test Plan: ./validate with new tests

Reviewers: hvr, goldfire, bgamari, simonmar

Subscribers: Abhiroop, dfeuer, rwbarton, thomie, carter

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

bgamari added a commit to bgamari/ghc that referenced this pull request Oct 5, 2018

Add Int8# and Word8#
This is the first step of implementing:
ghc-proposals/ghc-proposals#74

The main highlights/changes:

- `primops.txt.pp` gets two new sections for two new primitive types
  for signed and unsigned 8-bit integers (`Int8#` and `Word8`
  respectively) along with basic arithmetic and comparison
  operations. `PrimRep`/`RuntimeRep` get two new constructors for
  them. All of the primops translate into the existing `MachOP`s.

- For `CmmCall`s the codegen will now zero-extend the values at call
  site (so that they can be moved to the right register) and then
  truncate them back their original width.

- x86 native codegen needed some updates, since it wasn't able to deal
  with the new widths, but all the changes are quite localized. LLVM
  backend seems to just work.

Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com>

Test Plan: ./validate with new tests

Reviewers: hvr, goldfire, bgamari, simonmar

Subscribers: Abhiroop, dfeuer, rwbarton, thomie, carter

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

bgamari added a commit to bgamari/ghc that referenced this pull request Oct 7, 2018

Add Int8# and Word8#
This is the first step of implementing:
ghc-proposals/ghc-proposals#74

The main highlights/changes:

- `primops.txt.pp` gets two new sections for two new primitive types
  for signed and unsigned 8-bit integers (`Int8#` and `Word8`
  respectively) along with basic arithmetic and comparison
  operations. `PrimRep`/`RuntimeRep` get two new constructors for
  them. All of the primops translate into the existing `MachOP`s.

- For `CmmCall`s the codegen will now zero-extend the values at call
  site (so that they can be moved to the right register) and then
  truncate them back their original width.

- x86 native codegen needed some updates, since it wasn't able to deal
  with the new widths, but all the changes are quite localized. LLVM
  backend seems to just work.

Bumps binary submodule.

Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com>

Test Plan: ./validate with new tests

Reviewers: hvr, goldfire, bgamari, simonmar

Subscribers: Abhiroop, dfeuer, rwbarton, thomie, carter

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

bgamari added a commit to bgamari/ghc that referenced this pull request Oct 7, 2018

Add Int8# and Word8#
This is the first step of implementing:
ghc-proposals/ghc-proposals#74

The main highlights/changes:

- `primops.txt.pp` gets two new sections for two new primitive types
  for signed and unsigned 8-bit integers (`Int8#` and `Word8`
  respectively) along with basic arithmetic and comparison
  operations. `PrimRep`/`RuntimeRep` get two new constructors for
  them. All of the primops translate into the existing `MachOP`s.

- For `CmmCall`s the codegen will now zero-extend the values at call
  site (so that they can be moved to the right register) and then
  truncate them back their original width.

- x86 native codegen needed some updates, since it wasn't able to deal
  with the new widths, but all the changes are quite localized. LLVM
  backend seems to just work.

Bumps binary submodule.

Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com>

Test Plan: ./validate with new tests

Reviewers: hvr, goldfire, bgamari, simonmar

Subscribers: Abhiroop, dfeuer, rwbarton, thomie, carter

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

bgamari added a commit to ghc/ghc that referenced this pull request Nov 2, 2018

Add Int8# and Word8#
This is the first step of implementing:
ghc-proposals/ghc-proposals#74

The main highlights/changes:

    primops.txt.pp gets two new sections for two new primitive types for
    signed and unsigned 8-bit integers (Int8# and Word8 respectively) along
    with basic arithmetic and comparison operations. PrimRep/RuntimeRep get
    two new constructors for them. All of the primops translate into the
    existing MachOPs.

    For CmmCalls the codegen will now zero-extend the values at call
    site (so that they can be moved to the right register) and then truncate
    them back their original width.

    x86 native codegen needed some updates, since it wasn't able to deal
    with the new widths, but all the changes are quite localized. LLVM
    backend seems to just work.

This is the second attempt at merging this, after the first attempt in
D4475 had to be backed out due to regressions on i386.

Bumps binary submodule.

Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com>

Test Plan: ./validate (on both x86-{32,64})

Reviewers: bgamari, hvr, goldfire, simonmar

Subscribers: rwbarton, carter

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

@bravit bravit added the Proposal label Nov 11, 2018

@Ericson2314

This comment has been minimized.

Copy link

commented Jun 14, 2019

What about literals?

@michalt

This comment has been minimized.

Copy link
Contributor Author

commented Jun 15, 2019

@Ericson2314 This proposal did not include literals on purpose -- I think that deserves a separate proposal to make sure we come up with a reasonable syntax.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.