[llvm-dev] Outreachy dcoumentation project
Daniel Sanders via llvm-dev
llvm-dev at lists.llvm.org
Thu Jun 10 11:57:29 PDT 2021
Thanks David and Jessica, I probably wouldn't have noticed this thread from the title.
> On Jun 10, 2021, at 10:12, David Blaikie via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> +Jessica - I think she's got context on GlobalISel and might be able to rope in other folks with context if needed.
> On Wed, Jun 9, 2021 at 10:03 PM Pooja Yadav via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> Hi everyone!
> I am Pooja Yadav, an outreachy intern and I am working on the project "Create Documentation and Tutorials for the LLVM Global Instruction Selection Framework". I have been going through the documents and tutorials of GISel and I thought to list out the updates that should be made. It would be very helpful if anyone wants to add anything to the list or if they think something needs to be updated or added in the documentation.
> 1. Adding https://llvm.org/docs/GlobalISel/index.html <https://llvm.org/docs/GlobalISel/index.html> before this-https://llvm.org/docs/GlobalISel/GenericOpcode.html#g-fence <https://llvm.org/docs/GlobalISel/GenericOpcode.html#g-fence>
I'm not sure what you mean for this one. The index currently links to GenericOpcode.html in this section: https://llvm.org/docs/GlobalISel/index.html#design-and-implementation-reference
> 2. https://llvm.org/docs/GlobalISel/GenericOpcode.html#g-fence <https://llvm.org/docs/GlobalISel/GenericOpcode.html#g-fence> . There are many opcodes like this one that need documenting.
Definitely. Most of the instructions also need documentation on the type constraints (e.g. G_ADD only has one type and all three operands must agree on it, also G_PTR_ADD's first type must be a pointer), and any limitations on the types (e.g. G_MERGE_VALUES result must have the same number of bits as the sum of the operand sizes).
It really ought to be tied into the source somehow so people update the docs as they change things too. I don't know of a good way to do this though.
As an aside, if we're using a new enough version of pygments I added a syntax highlighter we can be using on the code examples.
> 3. There are some TODOs that I am listing here . Need help to find out whether these TODOs been implemented so that I can try updating the documentation regarding these:
> https://llvm.org/docs/GlobalISel/IRTranslator.html#aggregates <https://llvm.org/docs/GlobalISel/IRTranslator.html#aggregates>
I'm afraid I haven't dug into this section.
> https://llvm.org/docs/GlobalISel/Legalizer.html#api-legalizerinfo <https://llvm.org/docs/GlobalISel/Legalizer.html#api-legalizerinfo>
You mean the bit about using std::function? I did some work towards this fairly recently but I haven't got it working yet. The main problem is that calling LegalizerHelper methods from LegalizerInfo without some kind of indirection (like the LegalizerAction enum provides) is tricky. We're currently cheating a bit with custom rules as their implementation is in the LegalizerInfo which was meant to describe what needs to happen, rather than exactly how to do it.
> https://llvm.org/docs/GlobalISel/RegBankSelect.html#api-registerbankinfo <https://llvm.org/docs/GlobalISel/RegBankSelect.html#api-registerbankinfo>
Quentin and Matt might be able to help with this bit.
Hope this helps
> Some feedback on this would be very helpful.
> Thank you!
> Pooja Yadav
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev