arcana-lab / memoir Goto Github PK

To better organize the testing framework, I have added cmemoir/test.hpp, which allows you to register tests and expected outputs.

int main() {
  TEST(my_test) {
    int x = 0;
    expect(x == 0, "x not equal to 0");
  }
}

Low priority, but all existing tests should be ported to this structure.

Might be a somewhat stupid question about C++ namespaces. I was always assuming that
memoir::Struct::getType() would be of type memoir::StructType as opposed to llvm::StructType.

Therefore, getNumFields, should be available. But in

The compiler emits an error as it is believing it to be an LLVM type instead.

I apologzie if this is a little too stupid but am a little curious on if i somehow misunderstood the namespaces.

To allow passes to inject their own information into the program, and have it be more stable than metadata, we will add a function to do just that

memoir_property(PROPERTY_ID, ...)

PROPERTY_ID will be a unique ID for the given property. To simplify the compiler, this will be a string (const char *

A property takes an arbitrary number of arguments, allowing developers to implement properties however they want.

The Property base class will be implemented for developers to extend.

I am running commit : e0c6536. In particular the test function

On test struct_ref

It would appear an error is thrown when attempting to get the type of the struct accessed for a struct write instruction that write to a nested (by reference) struct.

We want to implement a hotness profiler to measure the hotness of a field within a given type.

The include directory structure needs to be fixed so that users can rely on it.
This issue is a location for discussion about the include directory, and will turn into a branch with the solution.

To allow users to more naturally represent sets, and allow SSA destruction to utilize set implementations for associative collections that do not use their value, add support for the void type element.

Sequences with void element types are currently unsupported, as I see no immediate use for them that couldn't be replaced with a single integer and simple for loops over scalars.

The Verifier will take a program and check the following conditions are met:

1. The program is a valid LLVM program (using LLVM's verifier)
2. All collections in the program maintain linearity (i.e., each collection can be typed linearly)
3. (optional) The above check can be weakened, and instead check for affine typing, which does not require a collection to be used (this would essentially require that each collection also be deleted)
4. (optional) For users who want to restrict the program to Gated Single Assignment (GSA) form, an irreducible control flow check can be added.

The goal of this verifier is to make assumptions explicit for passes that deal with destruction of MEMOIR collections.

Add support for C-style pointers, generalize it as:

void *readPointer(field)
writePointer(field, void *ptr)

The developer is responsible for casting the void * to whatever pointer type they need.

In commit 9e68fb5 , the struct summary for test case test_correct_nested_type should return something like
(struct uint64 (struct uint64 uint64 ) uint64 uint64 )

but the actual result is
(struct uint64 (struct uint64 uint64 ) ) where the rest of the fields are ignored after a nested objected is inserted.

The objectlowering pass is modified to just print this out for this test case as a method of reproduction

The issue can be reproduced by commit 6493b05 and in reference to the test case test_recursive_type.

In the test case, if one tries to get the allocation summary of Object *myB = allocateStruct(bTy); where bTy is

Type *bTy = defineStructType("B",
                             2,
                             ReferenceType(StructType("A")),
                             ReferenceType(StructType("B")));

One can get that summary but printing out the type doesn't terminate, which seems to imply something a bit weird since the to string function just loops through the fields?

We need to implement a basic mechanism for object splicing optimizations (splitting/merging) that works on memoir types and patches up the related objects and their field references.

memoir_rfold will have the same format as memoir_fold

FoldInst will be extended with a query to check if the fold is reverse or not.

This issue will track progress on upgrading MEMOIR to LLVM18.

Once closed, the current main branch will be renamed to v9 and v18 will become main.

General problems that fall under this issue:

• Migrate to new pass manager
• Handle opaque pointers by default, this will require either metadata or new API calls for typing

Slice and concatenation operations require the compiler to identify and analyze diamond patterns that make engineering (and compilation time) expensive.

To remedy this, we need to encapsulate the most common of these operations in their own general-purpose operations.

Insert element.
s' = INS(s, [i] = v)
Insert range.
s' = INS(s, [i], s_ins)

Remove element.
s' = RMV(s, [i])
Remove range.
s' = RMV(s, [i:j])

Additionally, the semantics of slice will change to be a view:
s0 = s[i:j]

With this the mut2ssa transformations look as follows:

insert(s, i, v)       ==> s' = INS([i], v, s)
insert(s, i, s2)      ==> s' = INS([i], s2, s)
remove(s, i)          ==> s' = RMV([i], s)
remove(s, i, j)       ==> s' = RMV([i:j], s)
append(s, s2)         ==> s' = INS([end], s2, s)
swap(s, i, j, k)      ==> s0 = s[k:k+j-i]
                          s1 = DEF(s[i:j], s0)
                          s2 = s[i:j]
                          s' = DEF(s[k:k+j-i], s2)
swap(s, i, j, s2, i2) ==> s0 = s2[i2:i2+j-i]
                          s' = DEF(s[i:j], s0)
                          s2 = s[i:j]
                          s2' = DEF(s1[i2:i2+j-i], s2)
s2 = split(s, i, j)   ==> s2 = s[i:j]
                          s' = RMV([i:j], s)

This issue exists to nail down details of the change and work out any kinks before implementation.

This issue exists to create a standardization for how source-code documentation is handled, with the intent of selecting a documentation generator.

This issue can be reproduced by commit 3e19e57 and is also in reference to test_recursive_type.

The access analysis is failed to get access summary of Object *ptrToA = readReference(tmpField);

I am also seeing some cases here where even though there are only one TyB, the two types obtained from the two objects that built from this object do not have pointer equality. I suspect this has something to do with this problem as well.

We need to implement a basic mechanism for reordering fields within a given memoir type and patches up the related objects and their field references.

in commit 326f3e2 , against https://github.com/arcana-lab/object-ir/blob/326f3e248b1d2f636b6bce1ac8475e9f21aa2024/tests/unit/test_tensor_really_simple/main.cpp .

I know this is against the old branch, but i couldn't get the new one (changed access api) to compile. I suspect the same issue would persist.

The printed number of dimensions and the size value is incorrect.

TensorType::getNumberOfDimensions() throws segfaults :

Test code:

Testing against the test:

This issue tracks progress on the C++-specific library for MEMOIR, specifically trying to provide a natural drop-in replacement for stl collections.

In Commit:
bc1e3ef

There is a test that just loops through the instructions, grabs the analysis content and does essentially nops:

However, running against test:
https://github.com/arcana-lab/memoir/blob/bc1e3efb289e86214c843e71217296208e836540/tests/unit/struct_ref/main.cpp

The following error has occurred as shown in the print out:

The fold will take a collection, an initial value, a function and an arbitrary number of closed arguments.

memoir_fold(collection, initial_value, function, closure...)

The instruction has the following semantics (in C++):

For sequences:

seq = ...
memoir_fold(init, seq, foo, closed...)

executes as:

auto accum = init;
for (size_t i = 0; i < memoir_size(seq); ++i) {
    auto val = memoir_read(seq, i);
    accum = foo(accum, i, val, closed...);
}

For associative collections:

assoc = ...
memoir_fold(init, assoc, foo, closed...)

executes as:

auto accum = init;
for (const auto [key, val] : assoc) {
    accum = foo(accum, key, val, closed...);
}

NOTE: At the moment, all closure arguments are immutable. To mutate a closed variable, it must be passed as a pointer, which will be loaded and stored in the function.

NOTE: the function used by a fold instruction must be statically known, and must be a top-level function in the module.

There should be a MEMOIR_HOME env variable for the makefile to select the location where memoir should be installed.

To allow us to more flexibly mark the output variables of a function (e.g., those that are introduced by SSA construction) without having to change the function signature, we will add the memoir_out_<n>(value) function.

SSA construction will insert instructions within the function to signal that a given reaching definition is the live-out of the function for the given argument.

fn my_function(a):
    mut_write(v, a, i);
    ret

becomes

fn my_function(a):
    b = memoir_write(v, a, i)
    memoir_out_0(b)
    ret

The memoir_out_<n> function is statically parameterized on the corresponding argument number.

SSA construction will also insert Ret PHI instructions after call sites to redefine the values passed into the function.

a = ...
call my_function(a)
b = memoir_retphi(a, @my_function)

The memoir_retphi function takes the variable that was passed as an argument and the function value being called.

NOTE: this may necessitate that the compiler perform hyperblocking to disambiguate cases such as x = p ? y : z.

Need to ensure that USE/DEF PHIs will dominate fellow users of a memoir collection.

To do this, we need to insert Control PHIs such that, for each memoir collection access that is reachable from another memoir collection access to the same memoir collection, a control PHI is inserted to maintain the dominance of the implicit USE/DEF PHI