Added advice for students - #100
Conversation
|
Two cents from years gone by: I found it difficult for many students to intuit the pure SSA model with Students have enough challenges in the course as it is, and I think you've only added more since I ran it. I'd present this less like a choice and more like "you should use the alloca model, but strive to understand what would happen if you wanted to do it the other way." Frankly, if clang doesn't bother at |
| placing the phi / block-argument merges yourself. | ||
|
|
||
| .. Warning:: | ||
| The SSA model is the more difficult of the two to implement, but can allow for more |
There was a problem hiding this comment.
Do you know for a fact that more optimizations can occur? I might be persuaded myself if you have a demonstrable example. My guess is that LLVM has a pass that does this for you, so that it can catch all the opportunities.
|
I think this stuff is great - thank you! I'm wondering if instead of a footnote in the spec, perhaps I could do a lecture on memory-less vs memory dialects in MLIR. I would have to work with you so that I can understand the nuances myself, unless you want to do the lecture yourself. |
|
I made the changes suggested. I wonder if I should just remove the SSA section entirely? |
Sir-NoChill
left a comment
Sir-NoChill
left a comment
There was a problem hiding this comment.
Looking good, but I think we should be deliberate about suggesting that the students use the tools that a dialect comes with by default to get some of the productivity, optimization and stylistic gains that MLIR can provide. I left some comments, I'd like to discuss them.
| you load from and store to, or as an SSA value that is defined once. **Use the | ||
| memory model.** It keeps code generation local and mechanical. The choice is the |
There was a problem hiding this comment.
I'm not sure we should outright suggest this. There is a good argument for using value-typed systems that FLang uses in FIR, namely they associate an fir expression that can grow and shrink (above memref) and then bufferize down to fir.box and fir.ref types with allocations. There is also precedent for this in the sparse_tensor dialect, which has a 'push_back' op that creates a new value type whenever adding an element to an array.
I agree that if the students were to implement this all themselves it just results in a ton of extra work, but they can steal from other dialects to make it somewhat easier. Especially with the bots, adopting the FIR/CLangIR methods would be effective in my mind.
There was a problem hiding this comment.
Could also point to the pytorch dialect that has the NonValueTensorType which might be a useful model. It exists above bufferization but is also mutable, I think that's the model we should follow in the solution.
There was a problem hiding this comment.
I think for this year, we should hold off on these types of improvements so the feedback from the change in evaluation is less noisy.
| *Scalars.* Map each variable name to its *current* SSA value: a read is a lookup, an | ||
| assignment produces a new value and rebinds the name. There are no slots and no |
There was a problem hiding this comment.
Might be useful to link to the bufferization documentation, since this comes with a little bit more nuance when you look at the bufferization passes: https://mlir.llvm.org/docs/Bufferization/#destination-passing-style
We may also want to discuss the composite types here too, and how MLIR can handle the destructuring for the students automatically. Probably pointing to toy ch7
| %0 = llvm.mlir.constant(128 : i64) : i64 | ||
| %1 = llvm.call @malloc(%0) : (i64) -> !llvm.ptr | ||
| llvm.call @free(%1) : (!llvm.ptr) -> () |
There was a problem hiding this comment.
I don't think the students should prefer to use the llvm dialect for the most part. In mlir this is supposed to be treated as a target dialect, rather than a dialect in which you write your IR, otherwise you just end up writing LLVM IR since MLIR cannot optimize LLVM IR (see the output dialects). I think we should prefer using func, memref and arith for this.
5 participants
I want the students to understand certain decisions that will affect them down the line when implementing their compilers.
I am a bit iffy on how it is presented. I appreciate criticism.