matthewbdwyer / tipc Goto Github PK

The latest stable release of llvm in homebrew has been upgraded to 11 and there is no alias to llvm10 available. This impacted at least one student building on mac. This seems like a bug/oversight in the homebrew formula - I'm hoping it will be fixed shortly. If not, we will have to find another way to install llvm10 or bump to 11.

To recreate, from a mac, run,

./bin/bootstrap.sh
...
Error: No available formula or cask with the name "llvm@10".
==> Searching for a previously deleted formula (in the last month)...

Relevant links:
brew docs: https://formulae.brew.sh/formula/llvm (notice no mention of llvm10)
git history: https://github.com/Homebrew/homebrew-core/commits/master/Formula/llvm.rb (notice the bump to 11 about a week ago)

We need to revisit each target and verify what libraries it is linking with. In some cases we are not linking enough.

For instance, the weeding pass does not link with AST, when it should.

Can download here https://plugins.jetbrains.com/plugin/7358-antlr-v4, it allows you to have a visual representation to parse tree.

We have some documentation, but for CLion it was not very smooth when I tried it. In particular there were some CMake issues and some issues in getting the catch2 tests up and running. As part of this I wonder whether we could integrate coverage reporting into these IDEs, there must be a way of doing this.

This change is in place for absent fields, but we still use "[[" instead of "\u27E6", "]]" for "\u27E7", and "&" for "\u2B61". These changes are easy to make in the type definitions, but they will require a bunch of changes to the test cases. So we may want to hold off for the next maintenance cycle.

Variable y in test case https://github.com/matthewbdwyer/tipc/blob/master/test/ptr6.tip has type conflict

The Line #6-7 implies that y is

• a ptr to an unknown ptr (null)
• a ptr to integer (13)

  y = alloc null;
  *y = 13;

Without type analysis, it can run in both tipc and TIP with no crush. I guess it works in tipc because both types are compiled to int64.

Is this a dedicated type-error test case?

The current pipeline will report success even if unit tests fail.

This is because the find command that runs the tests always exits with status 0. - https://github.com/matthewbdwyer/tipc/blob/main/bin/runtests.sh#L21

Building the project with make (but not running cmake ..) produces the following warning each time.

CMake Deprecation Warning at CMakeLists.txt:2 (cmake_minimum_required):
  Compatibility with CMake < 2.8.12 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value or use a ...<max> suffix to tell
  CMake that the project does not need compatibility with older versions.


-- Building without demo. To enable demo build use: -DWITH_DEMO=True
CMake Deprecation Warning at CMakeLists.txt:31 (CMAKE_POLICY):
  The OLD behavior for policy CMP0054 will be removed from a future version
  of CMake.

  The cmake-policies(7) manual explains that the OLD behaviors of all
  policies are deprecated and that a policy should be set to OLD only under
  specific short-term circumstances.  Projects should be ported to the NEW
  behavior and not rely on setting a policy to OLD.


CMake Deprecation Warning at CMakeLists.txt:32 (CMAKE_POLICY):
  The OLD behavior for policy CMP0045 will be removed from a future version
  of CMake.

  The cmake-policies(7) manual explains that the OLD behaviors of all
  policies are deprecated and that a policy should be set to OLD only under
  specific short-term circumstances.  Projects should be ported to the NEW
  behavior and not rely on setting a policy to OLD.


CMake Deprecation Warning at CMakeLists.txt:33 (CMAKE_POLICY):
  The OLD behavior for policy CMP0042 will be removed from a future version
  of CMake.

  The cmake-policies(7) manual explains that the OLD behaviors of all
  policies are deprecated and that a policy should be set to OLD only under
  specific short-term circumstances.  Projects should be ported to the NEW
  behavior and not rely on setting a policy to OLD.


CMake Deprecation Warning at CMakeLists.txt:38 (CMAKE_POLICY):
  The OLD behavior for policy CMP0059 will be removed from a future version
  of CMake.

  The cmake-policies(7) manual explains that the OLD behaviors of all
  policies are deprecated and that a policy should be set to OLD only under
  specific short-term circumstances.  Projects should be ported to the NEW
  behavior and not rely on setting a policy to OLD.


CMake Deprecation Warning at CMakeLists.txt:39 (CMAKE_POLICY):
  The OLD behavior for policy CMP0054 will be removed from a future version
  of CMake.

  The cmake-policies(7) manual explains that the OLD behaviors of all
  policies are deprecated and that a policy should be set to OLD only under
  specific short-term circumstances.  Projects should be ported to the NEW
  behavior and not rely on setting a policy to OLD.

This will allow a much wider range of optimizations to be applied.

Fix the pretty printer to not emit such spaces and modify expected results appropriately.

• Support arch os uname identification and bootstrap calls
• Handle package installation and versioning control via pacman
• Handle external repositories via yay or paru

in /bin/bootstrap.sh

Should the error be thrown? https://github.com/matthewbdwyer/tipc/blob/master/src/TIPtreeBuild.cpp#L39

Otherwise, why keep an instance there?

We discussed this issue in the slack group, and it looks like the command waits for the Sudo password. Perhaps printing a message that asks for the password would help?

TIP relational operators (like z > 3) produce i1 values in the generated bitcode, but TIP variables are alloca'd as i64s. As a result, if a valid TIP program tries to store the result of a comparison in a variable, invalid bitcode will be emitted.

bug.tip:

main(z) {
    var x;
    x = z > 3;
    return x;
}

bug.tip.ll obtained by running ./bin/build.sh --asm -do bug.tip:

; ModuleID = 'bug.tip'
source_filename = "bug.tip"
target triple = "arm64-apple-darwin21.4.0"

@_tip_ftable = internal constant [1 x i64 ()*] [i64 ()* @_tip_main]
@_tip_num_inputs = constant i64 1
@_tip_input_array = common global [1 x i64] zeroinitializer

; Function Attrs: nofree nosync nounwind readnone willreturn
declare void @llvm.donothing() #0

define i64 @_tip_main() {
entry:
  %x = alloca i64, align 8
  %z = alloca i64, align 8
  %tipinput0 = load i64, i64* getelementptr inbounds ([1 x i64], [1 x i64]* @_tip_input_array, i64 0, i64 0), align 4
  store i64 %tipinput0, i64* %z, align 4
  store i64 0, i64* %x, align 4
  %z1 = load i64, i64* %z, align 4
  %gttmp = icmp sgt i64 %z1, 3
  store i1 %gttmp, i64* %x, align 1
  %x2 = load i64, i64* %x, align 4
  ret i64 %x2
}

; Function Attrs: nounwind
declare noalias i8* @calloc(i64, i64) #1

attributes #0 = { nofree nosync nounwind readnone willreturn }
attributes #1 = { nounwind }

Output of llc bug.tip.ll:

llc: error: llc: bug.tip.ll:21:9: error: stored value and pointer type do not match
  store i1 %gttmp, i64* %x, align 1
        ^

There is an opportunity to make the type inference log messages more informative. In particular to help students understand potential errors in the formulation of type constraints for extensions to the type system. These would be along the lines of "successfully unified X and Y (if you did not expect these to be unified look at the implementation of the "==" operator for X and Y)"

upgrade to llvm 14; requires use of the new pass manager

The VS Code documentation needs to be updated to configure makefiles as the build system. This will also require an update to the settings.json file.

When adding types you need to subtype TipCons and store any type sub-expressions in its vector field in order for the unification algorithm to function correctly.

CMake build should be able to work with whatever minor+patch version homebrew pulls in. We need to make version matching less strict

This will avoid message like:

warning: overriding the module target triple with x86_64-apple-macosx11.0.0 [-Woverride-module]
1 warning generated.

on the Mac

The TIPC build compiles static libraries, but it doesn't seem to properly use them for some reason. When a file is modified, it is often recompiled up to 7 times per build depending on what part of the project it's in. This results in significantly increased build times.

The following screenshot illustrates the issue as it manifests with modifications to the type unifier.

The unifier is recompiled to a .o file seven times, once per artifact. Ideally, it should be compiled once into a static library, which should just be linked when needed rather than recompiling each time.

Unfortunately, I don't know CMake well enough to point out the specific issue in the build process leading to this behavior.

Disable it by default, but have the functionality implemented so that when extensions are available they can be correctly typed.

LCOV version 2.0 was released earlier this year. It is now the default version distributed by homebrew.

It seems tipc is incompatible with version 2.x. bin/gencov.sh leads to errors.

$ ./bin/gencov.sh
...
Processing /opt/devel/repos/sipc/build/src/semantic/weeding/CMakeFiles/weeding.dir/CheckAssignable.cpp.gcda
Processing /opt/devel/repos/sipc/build/src/error/CMakeFiles/error.dir/Error.cpp.gcda
Excluded data for 145 files due to include/exclude options
geninfo: ERROR: "/opt/devel/repos/sipc/src/semantic/types/solver/Substituter.h":7:  function _ZN11SubstituterD1Ev found on line but no corresponding 'line' coverage data point.  Cannot derive function end line.
...

Downgrading to version 1.x fixes the error.

Portal currently provides 1.14.

$ lcov -version
lcov: LCOV version 1.14

Having not totally migrated to shared_ptrs from unique_ptrs when implementing iterators has caused confusion. Let's finish the migration of the ASTNodes

Right now the code generator boils everything down to INT64 and then uses information about expression operand types (for type correct programs) to perform casting. We can drop the casts if we actually use the inferred types. A challenge here is that LLVM's type system is not as rich as TIP's so we will still need to generate type casts, e.g., for functions, but this will remove casts for pointer values.

This issue is a continuation of a discussion started in class on Tue, Nov 22.

While extending codegen for the class project, I sometimes make mistakes and my compiler erroneously emits invalid bitcode. In these situations tipc exits successfully, but linking the malformed .bc fails with the enigmatic error: Invalid record (Producer: 'LLVM14.0.6' Reader: 'LLVM 14.0.6').

In these cases I can often get a more descriptive error message by running ./bin/build.sh --asm problem.tip && llc problem.tip.ll.

Would it be possible to integrate llc-style bitcode validation in tipc? That way invalid bitcode is caught by tipc and we can emit a more informative error message instead of waiting for linking to fail.

The string is "%lld" which works for int64_t on some platforms, but issues warnings on others. For example,

tip_rtlib.c:56:50: warning: format specifies type 'long long' but the argument has type 'int64_t' (aka 'long') [-Wformat]

We want to rework the test helpers so that the order of constraints is not important. Also we want to allow for some flexibility in expressing the constraints, but this is tricky to get at with just a textual test oracle. What we really want is an oracle that checks logical equivalence between constraints for each AST sub-tree.

I noticed the jobs are hanging for Ubuntu builds and I think that is because the runner version we use has been removed. Will just need to move to a more recent version.

Constraint collector tests are pretty brittle, but there is not an obvious way to improve them. We should try to minimize these tests and instead focus most testing on the resultant type judgements produced which would be much more robust to different forms of constraint generation.

#69 replaces the unique_ptrs in the ast nodes with shared_ptrs. For the sake of consistency and simplicity for students, lets just use shared_ptrs everywhere.

As zsh is now the default shell on macOS, the bootstrap script should be able to set environment variables in ~/.zprofile.

My guess is that some of these warnings will turn into errors over time as Cmake deprecates functionality. Is this as easy as running the appropriate cmake policy commands, e.g., "cmake --help-policy CMP0114", in the bootstrap script?

This is just a yearly effort to track the latest LLVM. Biggest issue here is updating to the new pass manager.

It looks like since fbb9aa38 codecoverage has dropped to 0%. Need to figure out what broke and fix this,

Also change documentation of optimizer to be more tutorial.

This should be done after a post-mortem of the kinds of errors students made in implementing their projects.

The current version could do a thorough pass streamlining and simplifying it.

Write helpers to make expressing such tests easy

Constraint solving is fine, but the actual construction of the edges should only involve ASTFunAppExpr. The addition of edges when processing ASTVariable introduces more edges than is required. Also we should add a log message.

To assist with grading and debugging, we want to add a measure to stop the compiler at different phases and output the results. I.E. stop after type checking is done to ensure the right types are generated.