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

Update to v0.3.0 of llir/llvm. #27

Merged
merged 2 commits into from
Dec 30, 2019
Merged

Conversation

mewmew
Copy link
Contributor

@mewmew mewmew commented Dec 30, 2019

There were two main changes of llir/llvm that required updates in Geode,
namely:

  1. The sanity type-checks proposed in ir: proposal: typecheck more things llir/llvm#65 and added in PR
    Type check NewStore operands llir/llvm#72.
  2. The API update of NewLoad, NewStore, NewGetElementPtr which added
    a elemType argument in preparation for opaque pointer types of the
    official LLVM project (see proposal: API change, add elemType parameter to getelementptr constructors llir/llvm#112).

To resolve 1), an Equal method was added to StructType and SliceType of
gtypes.

To resolve 2) the element type was passed as the first argument to
NewLoad, NewStore and NewGetElementPtr.

Note, we've definitely noticed that working with user-defined types is
difficult and does not work well with the extensive type-switching used
in llir/llvm. The user-defined types (structs with names and slices) of
Geode have been very helpful to get a better understanding of this
limitation of llir/llvm. This has been outlined in llir/llvm#59 (comment)
and we hope to get a better design for sumtypes to allow user-defined
types, values, constants, instructions, etc.

One step at the time :)

I'm still very happy that you started the Geode project Nick as I've
learnt a lot from it and continue to learn more.

Wish you all the best and a most lovely start of the new year.

Cheers,
Robin

As part of PR geode-lang#24, Geode switched to using an unmodified version of
llir/llvm, as such the old copy of llvm is no longer needed.
There were two main changes of llir/llvm that required updates in Geode,
namely:

1) The sanity type-checks proposed in llir/llvm#65 and added in PR
   llir/llvm#72.
2) The API update of NewLoad, NewStore, NewGetElementPtr which added
   a elemType argument in preparation for opaque pointer types of the
   official LLVM project (see llir/llvm#112).

To resolve 1), an Equal method was added to StructType and SliceType of
gtypes.

To resolve 2) the element type was passed as the first argument to
NewLoad, NewStore and NewGetElementPtr.

Note, we've definitely noticed that working with user-defined types is
difficult and does not work well with the extensive type-switching used
in llir/llvm. The user-defined types (structs with names and slices) of
Geode have been very helpful to get a better understanding of this
limitation of llir/llvm. This has been outlined in llir/llvm#59 (comment)
and we hope to get a better design for sumtypes to allow user-defined
types, values, constants, instructions, etc.

One step at the time :)

I'm still very happy that you started the Geode project Nick as I've
learnt a lot from it and continue to learn more.

Wish you all the best and a most lovely start of the new year.

Cheers,
Robin
@mewmew
Copy link
Contributor Author

mewmew commented Dec 30, 2019

Oh, and just as a side-note, with this PR, all test cases of Geode are passing:

$ geode test
(1)	OKAY after return
(2)	OKAY arithmetic
(3)	OKAY array declaration 1
(4)	OKAY array declaration 2
(5)	OKAY classes 1 (Type Declaration)
(6)	OKAY classes 2 (Assigning and Accessing)
(7)	OKAY fibonacci
(8)	OKAY FizzBuzz
(9)	OKAY For Loops
(10)	OKAY global variables 1
(11)	OKAY global variables 2
(12)	OKAY global variables 3
(13)	OKAY global variables 4
(14)	OKAY Hello world
(15)	OKAY Conditional nesting
(16)	OKAY link
(17)	OKAY Minimal Program
(18)	OKAY Unicode 1: Function Names
(19)	OKAY Unicode 2: Variable Names
(20)	OKAY Unicode 3: String contents
(21)	OKAY unknown types 1
(22)	OKAY unknown types 2
(23)	OKAY while
->	23/23 (100%) tests ran successfully

@nickwanninger
Copy link
Collaborator

nickwanninger commented Dec 30, 2019

Awesome! Really appreciate the work upgrading dependent projects whenever you change the dependency's API - really admirable!

Happy new year to you as well :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants