2020-08-27

From yesterday:

Tomorrow, let's add some tests and try to integrate those changes in ReuseAllocations

Hereby integrated and tested.

However, we still have an undefined in optimiseKernel. The trouble here is that segmented operations other than SegMap have multiple bodies: A SegRed for example, has a main body, and a number of reduction lambdas. How do I know which of these to perform my allocations in? Right now, I'm analysing a SegOp, so the graph and coloring I get out is for both main body and reduction lambdas. Perhaps I need to separate optimising the main body and the reduction lambdas? Ask Troels.

Troels says: Disregard the operators in SegScan, SegRed and SegHist. This simplifies things a lot.

After some additional fixes, I can now actually successfully run the optimiser on OptionPricing.fut. Whether the generated code is still valid is still an open question. I'm trying to read it in as an sexp.

https://github.com/diku-dk/futhark/pull/1103

https://github.com/diku-dk/futhark/pull/1104

After those have been merged, I should probably rebase all of sexp to clean it up a bit.

Ugh, there are problems with the CI Windows build… Troels recently upgraded ghc to 8.8.4, perhaps that's the cause? Let's try with 8.8.3 (even though we previously used 8.8.2) and another tool called setup-haskell instead of manually calling chocolatey.

I don't think it's a problem with my code, so I've merged the pull requests now. We'll see if it causes any problems.

Cosmin proposed starting to think about coalescing. He has a relevant PLDI paper (I think this is it).

There's a problem with my LastUse analysis, which causes the generated code for OptionPricing to be invalid!

cabal run futhark -- dev --kernels -a -e --cse -e futhark-benchmarks/finpar/OptionPricing.fut

Consider mem_23344. My analysis currently reports it as being last-used in the statement assigning to lw_dest_23227. But lw_dest_23227 is actually returned as the result of a big loop and is assigned to res_22622, which is used much later in the program (statement x_22902). Why does this happen?

For some reason mem_23344 is not in inuse_outside in statement x_22902.

Tomorrow, I need to figure out why.