Working on a project for Swift for TensorFlow, and I'm prototyping a possible solution to my problem by manually writing out the SIL. While doing this though, ran into a problem with the store instruction. My solution was to add the [trivial] option, but I had trouble finding the solution as it seems load and store don't have any documentation regarding this. However copy_addr does though.
I'm unsure if there are other parts of the doc that is missing things like these and what are all the options, which is why I wanted to bring this up here before submitting a JIRA ticket.
I am still sort of out of the office. But I have an even more... evil, mischievious proposal.
background: I am not sure if you are aware but the SIL parser/printer has been a place where the Swift compiler has had technical debt for a long time that needs to be paid down. So matching the current implementation would mean I think matching whatever weirdness is inherent in it.
Thus, my evil, mischievious proposal: I wonder if there is a way that when it comes to the SIL parser we could square this circle by re-designing it in such a way that it could be imported into a swift program by the new work done by @pschuh.
Then you guys would just be able to have the full fidelity parser without needing to mess with anything. Additionally you could use our .def files to generate any auxillary data structures you need.
I think that using the C++ interop to bring the parser into Swift is a great approach. It also provides a testing mechanism for the bridging. However, having a proper document describing the SIL "language" a la LangRef is really important. It does more than describe how to parse the language - it explains the semantics of the language which is an aspect which would not be covered by simply making the parser available from Swift.
Sorry, upon re-reading I realized that OP was referring to the SIL docs, not to the other thread where someone is trying to write a SIL parser in swift separate from the actual c++ SIL parser (bad idea IMO since it will create maintenance burdens that we can avoid as mentioned above).
That being said. My suggestion is if you guys find anything missing from the docs, create a PR with a small change around there that you think is correct and lets talk about it on the PR. Then we can together push this forward.