On Mon, Jan 11, 2021 at 8:07 PM Stefanos Baziotis via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Hi Deep, > > 1) Kind of. There's Doxygen generated from source automatically, which > shows you many things e.g., members of a type along with some short > documentation (which is taken from the code). It also shows you the > inheritance tree related to this type > Here's an example: https://llvm.org/doxygen/classllvm_1_1LoopInfo.html > It doesn't really matter what this is for now, but you can see e.g., that > LoopInfo inherits from LoopInfoBase. If you scroll down, you can click to > different members and go to a more detailed description further down. You > can open the dropdown menus (e.g., public > functions inherited). And finally, at the top, you can see the file it > appears at. In general, I think that if you start clicking stuff, it's > going to make sense, it's relatively intuitive. > > 2) Try minimizing the number of parallel threads used. I think by default > Ninja uses all the available threads which in most machines will fill up > the RAM. To limit them, use the -j argument like this: ninja -j8 > Another thing that will probably be useful in general is that you can > choose to build specific sub-projects instead of building the whole thing, > like this: ninja -j8 opt >You can also use -DLLVM_PARALLEL_LINK_JOBS=<number> on your cmake command to limit just the number of linking jobs that can run in parallel. -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=ON can be a useful build configuration that you gets you debug logging and assertions, but you won't have debug symbols for gdb. There's also -DLLVM_USE_SPLIT_DWARF. All of these options are covered here https://llvm.org/docs/GettingStarted.html#common-problems> > 3) Ok, first of all, if you only care about editing and not debugging LLVM > (i.e. launching it with a debugger like gdb), then editors like Vim, Emacs, > 4coder, maybe Sublime Text should do the job. I think most people > developing LLVM on Linux use something like this. > > Now, if you're interested in IDEs and / or debuggers, well, the news in > Linux is bad IMHO. For example, in my machine, GDB takes _30 seconds_ to > launch the debug build of opt. > So, I couldn't use any IDE because virtually all use GDB under the hood. > Personally, I switched to Windows + Visual Studio just for this reason. > That was an insane productivity boost for me. > But if you need something that works in Linux, you can maybe try LLDB. > Hopefully it will be faster. If yes, you can maybe try hooking it in an > IDE, which I guess won't be trivial. > > That said, as I don't develop LLVM in Linux, other people might have > better suggestions. > > Best, > Stefanos > > Στις Τρί, 12 Ιαν 2021 στις 5:43 π.μ., ο/η Deep Majumder via llvm-dev < > llvm-dev at lists.llvm.org> έγραψε: > >> Hello everyone, >> I have been studying the LLVM IR and now want to get into LLVM >> development. I have a few questions regarding that and I would be really >> grateful to get answers for: >> >> 1) The LangRef is an excellent guide/reference to the IR. Is there >> something similar for the codebase (the core llvm to be specific)? Or do I >> have to generate that from the source, in which case how do I do that? >> 2) I tried building just the llvm sub-project, and that is filling up my >> RAM completely during the linking stages, and sends my laptop thrashing. I >> am using Ninja. Is there a way to mitigate this? (I am on Ubuntu 20.04 >> Linux, 8 GM RAM, 8 GM swap on an HDD). >> 3) VSCode, at least on my laptop, is very sluggish with such large a >> project. Is there any recommended development environment for Linux (or at >> least something that has been found to work well)? >> >> Thank you for your time! >> Regards, >> Deep >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210111/8654d8d2/attachment.html>
On Mon, Jan 11, 2021 at 8:33 PM Craig Topper via llvm-dev < llvm-dev at lists.llvm.org> wrote:> > On Mon, Jan 11, 2021 at 8:07 PM Stefanos Baziotis via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi Deep, >> >> 1) Kind of. There's Doxygen generated from source automatically, which >> shows you many things e.g., members of a type along with some short >> documentation (which is taken from the code). It also shows you the >> inheritance tree related to this type >> Here's an example: https://llvm.org/doxygen/classllvm_1_1LoopInfo.html >> It doesn't really matter what this is for now, but you can see e.g., that >> LoopInfo inherits from LoopInfoBase. If you scroll down, you can click to >> different members and go to a more detailed description further down. You >> can open the dropdown menus (e.g., public >> functions inherited). And finally, at the top, you can see the file it >> appears at. In general, I think that if you start clicking stuff, it's >> going to make sense, it's relatively intuitive. >> >> 2) Try minimizing the number of parallel threads used. I think by default >> Ninja uses all the available threads which in most machines will fill up >> the RAM. To limit them, use the -j argument like this: ninja -j8 >> Another thing that will probably be useful in general is that you can >> choose to build specific sub-projects instead of building the whole thing, >> like this: ninja -j8 opt >> > > You can also use -DLLVM_PARALLEL_LINK_JOBS=<number> on your cmake command > to limit just the number of linking jobs that can run in parallel. > -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=ON can be a useful > build configuration that you gets you debug logging and assertions, but you > won't have debug symbols for gdb. There's also -DLLVM_USE_SPLIT_DWARF. All > of these options are covered here > https://llvm.org/docs/GettingStarted.html#common-problems >On top of these, if you're on Linux I found that using LLD (or Gold) as a linker instead of the default bfd helps a lot with memory consumption (-DLLVM_ENABLE_LLD=ON)> > >> >> 3) Ok, first of all, if you only care about editing and not debugging >> LLVM (i.e. launching it with a debugger like gdb), then editors like Vim, >> Emacs, 4coder, maybe Sublime Text should do the job. I think most people >> developing LLVM on Linux use something like this. >> >> Now, if you're interested in IDEs and / or debuggers, well, the news in >> Linux is bad IMHO. For example, in my machine, GDB takes _30 seconds_ to >> launch the debug build of opt. >> So, I couldn't use any IDE because virtually all use GDB under the hood. >> Personally, I switched to Windows + Visual Studio just for this reason. >> That was an insane productivity boost for me. >> But if you need something that works in Linux, you can maybe try LLDB. >> Hopefully it will be faster. If yes, you can maybe try hooking it in an >> IDE, which I guess won't be trivial. >> >> That said, as I don't develop LLVM in Linux, other people might have >> better suggestions. >> >> Best, >> Stefanos >> >> Στις Τρί, 12 Ιαν 2021 στις 5:43 π.μ., ο/η Deep Majumder via llvm-dev < >> llvm-dev at lists.llvm.org> έγραψε: >> >>> Hello everyone, >>> I have been studying the LLVM IR and now want to get into LLVM >>> development. I have a few questions regarding that and I would be really >>> grateful to get answers for: >>> >>> 1) The LangRef is an excellent guide/reference to the IR. Is there >>> something similar for the codebase (the core llvm to be specific)? Or do I >>> have to generate that from the source, in which case how do I do that? >>> 2) I tried building just the llvm sub-project, and that is filling up my >>> RAM completely during the linking stages, and sends my laptop thrashing. I >>> am using Ninja. Is there a way to mitigate this? (I am on Ubuntu 20.04 >>> Linux, 8 GM RAM, 8 GM swap on an HDD). >>> 3) VSCode, at least on my laptop, is very sluggish with such large a >>> project. Is there any recommended development environment for Linux (or at >>> least something that has been found to work well)? >>> >>> Thank you for your time! >>> Regards, >>> Deep >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210111/d8376b23/attachment.html>
Thanks everyone for the advice! I am able to build LLVM now without causing my laptop to thrash. Also as I understand that for auto-complete in LLVM, Linux is not the best place to be. Also, thanks for the Doxygen-generated docs link. Warm regards, Deep On Tue, Jan 12, 2021 at 10:03 AM Craig Topper <craig.topper at gmail.com> wrote:> > On Mon, Jan 11, 2021 at 8:07 PM Stefanos Baziotis via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi Deep, >> >> 1) Kind of. There's Doxygen generated from source automatically, which >> shows you many things e.g., members of a type along with some short >> documentation (which is taken from the code). It also shows you the >> inheritance tree related to this type >> Here's an example: https://llvm.org/doxygen/classllvm_1_1LoopInfo.html >> It doesn't really matter what this is for now, but you can see e.g., that >> LoopInfo inherits from LoopInfoBase. If you scroll down, you can click to >> different members and go to a more detailed description further down. You >> can open the dropdown menus (e.g., public >> functions inherited). And finally, at the top, you can see the file it >> appears at. In general, I think that if you start clicking stuff, it's >> going to make sense, it's relatively intuitive. >> >> 2) Try minimizing the number of parallel threads used. I think by default >> Ninja uses all the available threads which in most machines will fill up >> the RAM. To limit them, use the -j argument like this: ninja -j8 >> Another thing that will probably be useful in general is that you can >> choose to build specific sub-projects instead of building the whole thing, >> like this: ninja -j8 opt >> > > You can also use -DLLVM_PARALLEL_LINK_JOBS=<number> on your cmake command > to limit just the number of linking jobs that can run in parallel. > -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=ON can be a useful > build configuration that you gets you debug logging and assertions, but you > won't have debug symbols for gdb. There's also -DLLVM_USE_SPLIT_DWARF. All > of these options are covered here > https://llvm.org/docs/GettingStarted.html#common-problems > > >> >> 3) Ok, first of all, if you only care about editing and not debugging >> LLVM (i.e. launching it with a debugger like gdb), then editors like Vim, >> Emacs, 4coder, maybe Sublime Text should do the job. I think most people >> developing LLVM on Linux use something like this. >> >> Now, if you're interested in IDEs and / or debuggers, well, the news in >> Linux is bad IMHO. For example, in my machine, GDB takes _30 seconds_ to >> launch the debug build of opt. >> So, I couldn't use any IDE because virtually all use GDB under the hood. >> Personally, I switched to Windows + Visual Studio just for this reason. >> That was an insane productivity boost for me. >> But if you need something that works in Linux, you can maybe try LLDB. >> Hopefully it will be faster. If yes, you can maybe try hooking it in an >> IDE, which I guess won't be trivial. >> >> That said, as I don't develop LLVM in Linux, other people might have >> better suggestions. >> >> Best, >> Stefanos >> >> Στις Τρί, 12 Ιαν 2021 στις 5:43 π.μ., ο/η Deep Majumder via llvm-dev < >> llvm-dev at lists.llvm.org> έγραψε: >> >>> Hello everyone, >>> I have been studying the LLVM IR and now want to get into LLVM >>> development. I have a few questions regarding that and I would be really >>> grateful to get answers for: >>> >>> 1) The LangRef is an excellent guide/reference to the IR. Is there >>> something similar for the codebase (the core llvm to be specific)? Or do I >>> have to generate that from the source, in which case how do I do that? >>> 2) I tried building just the llvm sub-project, and that is filling up my >>> RAM completely during the linking stages, and sends my laptop thrashing. I >>> am using Ninja. Is there a way to mitigate this? (I am on Ubuntu 20.04 >>> Linux, 8 GM RAM, 8 GM swap on an HDD). >>> 3) VSCode, at least on my laptop, is very sluggish with such large a >>> project. Is there any recommended development environment for Linux (or at >>> least something that has been found to work well)? >>> >>> Thank you for your time! >>> Regards, >>> Deep >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210112/2e40e5fb/attachment.html>