Quentin Colombet via llvm-dev
2017-Jan-14 01:54 UTC
[llvm-dev] RFC: Building GlobalISel by default
Hi all, Now, four backends (if I am counting right: X86, ARM, AArch64, AMDGPU) are working on bringing-up GlobalISel, I’d like to switch the default of the LLVM_BUILD_GLOBAL_ISEL variable in CMake, such that the framework gets built by default. ** Impact of Flipping the Switch ** * Upsides * For people developing on GlobalISel, it will: - Simplify the CMake command to type :) - Build/Test GlobalISel on all the LLVM bots For people not developing on GlobalISel, it will: - Test that GlobalISel still works with your changes (make check will test that for you) - Allow you to play with it! Basically flipping the default CMake setting will give access to all the ISel schemes that we have in LLVM, instead of just SDISel and FastISel. * Downsides * For people developing on GlobalISel, it will: - Leave the status as it is now, meaning that mainly only people working on GlobalISel look at the failures of GlobalISel specific bots For people not developing for GlobalISel, it will: - Increase the compile time since the GlobalISel framework and the related target specific parts will have to be built - Increase the size of the binary (depending on what backend you pull) - Require the setting of an additional CMake variable to disable it (-DLLVM_BUILD_GLOBAL_ISEL=OFF) What do people think? Thanks, -Quentin
Michael Kuperstein via llvm-dev
2017-Jan-14 02:38 UTC
[llvm-dev] RFC: Building GlobalISel by default
As a person not developing on GlobalISel, I can already play with it by setting the flag. ;-) The main (and huge) benefit I see is that it will get tested by default. So, I think it's mainly a question of maturity - if my (non-GlobalISel) change breaks GlobalISel, how likely is it to be a bug in my code vs. a bug in GlobalISel? Michael On Fri, Jan 13, 2017 at 5:54 PM, Quentin Colombet via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Hi all, > > Now, four backends (if I am counting right: X86, ARM, AArch64, AMDGPU) are > working on bringing-up GlobalISel, I’d like to switch the default of the > LLVM_BUILD_GLOBAL_ISEL variable in CMake, such that the framework gets > built by default. > > ** Impact of Flipping the Switch ** > > * Upsides * > > For people developing on GlobalISel, it will: > - Simplify the CMake command to type :) > - Build/Test GlobalISel on all the LLVM bots > > For people not developing on GlobalISel, it will: > - Test that GlobalISel still works with your changes (make check will test > that for you) > - Allow you to play with it! > > Basically flipping the default CMake setting will give access to all the > ISel schemes that we have in LLVM, instead of just SDISel and FastISel. > > * Downsides * > > For people developing on GlobalISel, it will: > - Leave the status as it is now, meaning that mainly only people working > on GlobalISel look at the failures of GlobalISel specific bots > > For people not developing for GlobalISel, it will: > - Increase the compile time since the GlobalISel framework and the related > target specific parts will have to be built > - Increase the size of the binary (depending on what backend you pull) > - Require the setting of an additional CMake variable to disable it > (-DLLVM_BUILD_GLOBAL_ISEL=OFF) > > > What do people think? > > Thanks, > -Quentin > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://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/20170113/e0a2971d/attachment.html>
Mehdi Amini via llvm-dev
2017-Jan-14 04:59 UTC
[llvm-dev] RFC: Building GlobalISel by default
Hi, I tend to view this positively, but I feel you could give a few more data, in particular to help answering the questions you raise below.> On Jan 13, 2017, at 5:54 PM, Quentin Colombet via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi all, > > Now, four backends (if I am counting right: X86, ARM, AArch64, AMDGPU) are working on bringing-up GlobalISel, I’d like to switch the default of the LLVM_BUILD_GLOBAL_ISEL variable in CMake, such that the framework gets built by default. > > ** Impact of Flipping the Switch ** > > * Upsides * > > For people developing on GlobalISel, it will: > - Simplify the CMake command to type :) > - Build/Test GlobalISel on all the LLVM bots > > For people not developing on GlobalISel, it will: > - Test that GlobalISel still works with your changes (make check will test that for you) > - Allow you to play with it! > > Basically flipping the default CMake setting will give access to all the ISel schemes that we have in LLVM, instead of just SDISel and FastISel. > > * Downsides * > > For people developing on GlobalISel, it will: > - Leave the status as it is now, meaning that mainly only people working on GlobalISel look at the failures of GlobalISel specific bots > > For people not developing for GlobalISel, it will: > - Increase the compile time since the GlobalISel framework and the related target specific parts will have to be builtHow long does it take to run `make check` from a clean LLVM build with and without GlobalISel enabled?> - Increase the size of the binary (depending on what backend you pull)How large is llc with only X86 and AArch64 configured in, with and without GlobalISel enabled? Thanks, Mehdi
Philip Reames via llvm-dev
2017-Jan-14 05:21 UTC
[llvm-dev] RFC: Building GlobalISel by default
I would lean towards doing this, but don't have an strong opinion either way. Would it be possible (in another thread) to get a brief status report of where we are with GlobalISEL overall? Philip On 01/13/2017 05:54 PM, Quentin Colombet via llvm-dev wrote:> Hi all, > > Now, four backends (if I am counting right: X86, ARM, AArch64, AMDGPU) are working on bringing-up GlobalISel, I’d like to switch the default of the LLVM_BUILD_GLOBAL_ISEL variable in CMake, such that the framework gets built by default. > > ** Impact of Flipping the Switch ** > > * Upsides * > > For people developing on GlobalISel, it will: > - Simplify the CMake command to type :) > - Build/Test GlobalISel on all the LLVM bots > > For people not developing on GlobalISel, it will: > - Test that GlobalISel still works with your changes (make check will test that for you) > - Allow you to play with it! > > Basically flipping the default CMake setting will give access to all the ISel schemes that we have in LLVM, instead of just SDISel and FastISel. > > * Downsides * > > For people developing on GlobalISel, it will: > - Leave the status as it is now, meaning that mainly only people working on GlobalISel look at the failures of GlobalISel specific bots > > For people not developing for GlobalISel, it will: > - Increase the compile time since the GlobalISel framework and the related target specific parts will have to be built > - Increase the size of the binary (depending on what backend you pull) > - Require the setting of an additional CMake variable to disable it (-DLLVM_BUILD_GLOBAL_ISEL=OFF) > > > What do people think? > > Thanks, > -Quentin > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Renato Golin via llvm-dev
2017-Jan-14 12:57 UTC
[llvm-dev] RFC: Building GlobalISel by default
On 14 January 2017 at 01:54, Quentin Colombet via llvm-dev <llvm-dev at lists.llvm.org> wrote:> Now, four backends (if I am counting right: X86, ARM, AArch64, AMDGPU) are working on bringing-up GlobalISel, I’d like to switch the default of the LLVM_BUILD_GLOBAL_ISEL variable in CMake, such that the framework gets built by default.Hi Quentin, I'm not extremely confident in a full switch right now, mainly due to Michael's concerns. The ARM port is in its initial stage and there could still be many refactorings and destructive changes. I'm not foreseeing a cross between the isel tests, but every failure makes the bots red, and if Global ISel incurs in more failures due to its stage in the development cycle, we'll start seeing the bots more red than we'd like. Right now, it's already very likely that you'll receive bot emails on commits, I don't want to increase that. One alternative is to create a buildbot that turns it on by default, build all back-ends that use GlobalISel and then let it running for a while. I don't think we're self-hosting on any architecture right now, nor we're passing the test-suites, so the bot will probably just be a simple "make check-all", which is more than enough for the time being. As soon as we can self-host and pass the test-suite, I think we can enable it by default. Some comments inline...> * Upsides * > > For people developing on GlobalISel, it will: > - Simplify the CMake command to type :) > - Build/Test GlobalISel on all the LLVM botsThis is already covered by the people developing Global ISel on the different architectures. As an experimental feature, I'm ok with the round time of "ARM developers picking up x86 code breaking their stuff".> For people not developing on GlobalISel, it will: > - Test that GlobalISel still works with your changes (make check will test that for you)A separate buildbot will do that for you.> - Allow you to play with it!The cost of adding one CMake option is really small.> * Downsides * > > For people developing on GlobalISel, it will: > - Leave the status as it is now, meaning that mainly only people working on GlobalISel look at the failures of GlobalISel specific botsIf we already have those, I don't see why we need more. We're not self-hosting not passing the test-suite. the "check-all" tests should not matter which platform they run.> For people not developing for GlobalISel, it will: > - Increase the compile time since the GlobalISel framework and the related target specific parts will have to be built > - Increase the size of the binary (depending on what backend you pull) > - Require the setting of an additional CMake variable to disable it (-DLLVM_BUILD_GLOBAL_ISEL=OFF)This has a higher impact on slow bots, such as ARM and MIPS, and it's not a trivial amount of time and space. On previous occasions (for example integrated-asm, lld, vecorizer), we have used the "self-host + test-suite passing" model and it worked well. Meaning, before it passes those two, it should have special buildbots, after, it can be turned on by default. To move to the new technology we need an additional step, which is to fix most remaining bugs, which we have done for the vectorizer and integrated-asm, but not lld, and that's why the two first are not only built by default, but enabled by default, while the latter isn't. I want Global ISel to be a success as much as you do, but I'd rather go through a smooth path, even if it takes a bit longer. cheers, --renato
Mehdi Amini via llvm-dev
2017-Jan-14 18:53 UTC
[llvm-dev] RFC: Building GlobalISel by default
> On Jan 14, 2017, at 4:57 AM, Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 14 January 2017 at 01:54, Quentin Colombet via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> Now, four backends (if I am counting right: X86, ARM, AArch64, AMDGPU) are working on bringing-up GlobalISel, I’d like to switch the default of the LLVM_BUILD_GLOBAL_ISEL variable in CMake, such that the framework gets built by default. > > Hi Quentin, > > I'm not extremely confident in a full switch right now, mainly due to > Michael's concerns. The ARM port is in its initial stage and there > could still be many refactorings and destructive changes. I'm not > foreseeing a cross between the isel tests, but every failure makes the > bots red, and if Global ISel incurs in more failures due to its stage > in the development cycle, we'll start seeing the bots more red than > we'd like. Right now, it's already very likely that you'll receive bot > emails on commits, I don't want to increase that.I don’t see why having global ISel is supposed to increase the rate. `make check` will runs on the committer machine with GlobalISel enabled. The good question from Michael is IMO "if my (non-GlobalISel) change breaks GlobalISel, how likely is it to be a bug in my code vs. a bug in GlobalISel?” But that’s totally unrelated to the bots, since it’ll fails on the committer machine as well.> > One alternative is to create a buildbot that turns it on by default, > build all back-ends that use GlobalISel and then let it running for a > while. I don't think we're self-hosting on any architecture right now, > nor we're passing the test-suites, so the bot will probably just be a > simple "make check-all", which is more than enough for the time being.This is in place for months: http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-globalisel/> > As soon as we can self-host and pass the test-suite, I think we can > enable it by default.I don’t understand why it is an interesting property to be able to pass the test-suite to have `make check` testing it.> > Some comments inline... > > >> * Upsides * >> >> For people developing on GlobalISel, it will: >> - Simplify the CMake command to type :) >> - Build/Test GlobalISel on all the LLVM bots > > This is already covered by the people developing Global ISel on the > different architectures. As an experimental feature, I'm ok with the > round time of "ARM developers picking up x86 code breaking their > stuff". > > >> For people not developing on GlobalISel, it will: >> - Test that GlobalISel still works with your changes (make check will test that for you) > > A separate buildbot will do that for you. > > >> - Allow you to play with it! > > The cost of adding one CMake option is really small. > > >> * Downsides * >> >> For people developing on GlobalISel, it will: >> - Leave the status as it is now, meaning that mainly only people working on GlobalISel look at the failures of GlobalISel specific bots > > If we already have those, I don't see why we need more. We're not > self-hosting not passing the test-suite. the "check-all" tests should > not matter which platform they run.The `check-all` are *not* testing GlobalISel right now because GlobalISel is not *built* on the bots. This is *exactly* the point of the proposal: have `make` building the global isel code on every platform, and have `make check` testing the lit-tests for GlobalISel on every platform. This is *not* about enabling GlobalISel *by default* on any target AFAIK. — Mehdi> > >> For people not developing for GlobalISel, it will: >> - Increase the compile time since the GlobalISel framework and the related target specific parts will have to be built >> - Increase the size of the binary (depending on what backend you pull) >> - Require the setting of an additional CMake variable to disable it (-DLLVM_BUILD_GLOBAL_ISEL=OFF) > > This has a higher impact on slow bots, such as ARM and MIPS, and it's > not a trivial amount of time and space. > > On previous occasions (for example integrated-asm, lld, vecorizer), we > have used the "self-host + test-suite passing" model and it worked > well. Meaning, before it passes those two, it should have special > buildbots, after, it can be turned on by default. > > To move to the new technology we need an additional step, which is to > fix most remaining bugs, which we have done for the vectorizer and > integrated-asm, but not lld, and that's why the two first are not only > built by default, but enabled by default, while the latter isn't. > > I want Global ISel to be a success as much as you do, but I'd rather > go through a smooth path, even if it takes a bit longer. > > cheers, > --renato > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Kristof Beyls via llvm-dev
2017-Jan-14 19:10 UTC
[llvm-dev] RFC: Building GlobalISel by default
On 14 Jan 2017, at 01:54, Quentin Colombet via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: * Upsides * For people developing on GlobalISel, it will: - Simplify the CMake command to type :) - Build/Test GlobalISel on all the LLVM bots I have one more upside for GlobalISel developers: It would start populating the llvmlab build cache with binaries that do have globalisel compiled in. It means that bisecting regressions in globalisel could be done using the llvmlab build cache. A minor self-ish upside for me personally is that the internal infrastructure I'm using uses an internal build cache; and most of our internal testing and benchmarking picks up the compiler binary from that build cache. Having GlobalISel compiled in by default would help me in avoiding a bunch of infrastructure modifications before I'm able to benchmark GlobalISel vs traditional ISel on our internal benchmarks. This is probably just a very minor point, unless other GlobalISel developers have access to an internal infrastructure with similar properties. Thanks, Kristof -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170114/e2c35578/attachment.html>
Renato Golin via llvm-dev
2017-Jan-14 19:25 UTC
[llvm-dev] RFC: Building GlobalISel by default
On 14 January 2017 at 19:10, Kristof Beyls via llvm-dev <llvm-dev at lists.llvm.org> wrote:> Having GlobalISel compiled in by default would help me in avoiding a bunch > of infrastructure modifications before I'm able to benchmark GlobalISel vs > traditional ISel on our internal benchmarks. > This is probably just a very minor point, unless other GlobalISel developers > have access to an internal infrastructure with similar properties.Can't you just enable GlobalISel on your internal buildbot? --renato
Reid Kleckner via llvm-dev
2017-Jan-17 18:01 UTC
[llvm-dev] RFC: Building GlobalISel by default
I'm in favor of building this by default. GlobalISel will eventually be the default, and people are actively working on it. We should iron out any build issues now to help with the transition. For example, if it comes with a substantial size hit, we should investigate and prioritize fixing that. On Fri, Jan 13, 2017 at 5:54 PM, Quentin Colombet via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Hi all, > > Now, four backends (if I am counting right: X86, ARM, AArch64, AMDGPU) are > working on bringing-up GlobalISel, I’d like to switch the default of the > LLVM_BUILD_GLOBAL_ISEL variable in CMake, such that the framework gets > built by default. > > ** Impact of Flipping the Switch ** > > * Upsides * > > For people developing on GlobalISel, it will: > - Simplify the CMake command to type :) > - Build/Test GlobalISel on all the LLVM bots > > For people not developing on GlobalISel, it will: > - Test that GlobalISel still works with your changes (make check will test > that for you) > - Allow you to play with it! > > Basically flipping the default CMake setting will give access to all the > ISel schemes that we have in LLVM, instead of just SDISel and FastISel. > > * Downsides * > > For people developing on GlobalISel, it will: > - Leave the status as it is now, meaning that mainly only people working > on GlobalISel look at the failures of GlobalISel specific bots > > For people not developing for GlobalISel, it will: > - Increase the compile time since the GlobalISel framework and the related > target specific parts will have to be built > - Increase the size of the binary (depending on what backend you pull) > - Require the setting of an additional CMake variable to disable it > (-DLLVM_BUILD_GLOBAL_ISEL=OFF) > > > What do people think? > > Thanks, > -Quentin > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://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/20170117/0b64ef6a/attachment.html>
Quentin Colombet via llvm-dev
2017-Jan-17 18:04 UTC
[llvm-dev] RFC: Building GlobalISel by default
Hi Michael,> On Jan 13, 2017, at 6:38 PM, Michael Kuperstein <mkuper at google.com> wrote: > > As a person not developing on GlobalISel, I can already play with it by setting the flag. ;-) > > The main (and huge) benefit I see is that it will get tested by default.I agree.> So, I think it's mainly a question of maturity - if my (non-GlobalISel) change breaks GlobalISel, how likely is it to be a bug in my code vs. a bug in GlobalISel?That’s very likely this is a bug in your code. GlobalISel test cases usually check the GlobalISel passes in isolation. Therefore, if they break without GlobalISel related passes being changed, that means that some of the core MI functionalities have been broken (e.g., some semantic with MachineRegisterInfo, the parsing of .mir files, this kind of thing). In other words, it is usually best for the author of the code to realize directly that the code break. Cheers, -Quentin> > Michael > > On Fri, Jan 13, 2017 at 5:54 PM, Quentin Colombet via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > Hi all, > > Now, four backends (if I am counting right: X86, ARM, AArch64, AMDGPU) are working on bringing-up GlobalISel, I’d like to switch the default of the LLVM_BUILD_GLOBAL_ISEL variable in CMake, such that the framework gets built by default. > > ** Impact of Flipping the Switch ** > > * Upsides * > > For people developing on GlobalISel, it will: > - Simplify the CMake command to type :) > - Build/Test GlobalISel on all the LLVM bots > > For people not developing on GlobalISel, it will: > - Test that GlobalISel still works with your changes (make check will test that for you) > - Allow you to play with it! > > Basically flipping the default CMake setting will give access to all the ISel schemes that we have in LLVM, instead of just SDISel and FastISel. > > * Downsides * > > For people developing on GlobalISel, it will: > - Leave the status as it is now, meaning that mainly only people working on GlobalISel look at the failures of GlobalISel specific bots > > For people not developing for GlobalISel, it will: > - Increase the compile time since the GlobalISel framework and the related target specific parts will have to be built > - Increase the size of the binary (depending on what backend you pull) > - Require the setting of an additional CMake variable to disable it (-DLLVM_BUILD_GLOBAL_ISEL=OFF) > > > What do people think? > > Thanks, > -Quentin > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://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/20170117/1448373b/attachment.html>
Quentin Colombet via llvm-dev
2017-Jan-18 04:39 UTC
[llvm-dev] RFC: Building GlobalISel by default
Hi Mehdi, I did quick measurements for what you were asking.> On Jan 13, 2017, at 8:59 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > Hi, > > I tend to view this positively, but I feel you could give a few more data, in particular to help answering the questions you raise below. > >> On Jan 13, 2017, at 5:54 PM, Quentin Colombet via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Hi all, >> >> Now, four backends (if I am counting right: X86, ARM, AArch64, AMDGPU) are working on bringing-up GlobalISel, I’d like to switch the default of the LLVM_BUILD_GLOBAL_ISEL variable in CMake, such that the framework gets built by default. >> >> ** Impact of Flipping the Switch ** >> >> * Upsides * >> >> For people developing on GlobalISel, it will: >> - Simplify the CMake command to type :) >> - Build/Test GlobalISel on all the LLVM bots >> >> For people not developing on GlobalISel, it will: >> - Test that GlobalISel still works with your changes (make check will test that for you) >> - Allow you to play with it! >> >> Basically flipping the default CMake setting will give access to all the ISel schemes that we have in LLVM, instead of just SDISel and FastISel. >> >> * Downsides * >> >> For people developing on GlobalISel, it will: >> - Leave the status as it is now, meaning that mainly only people working on GlobalISel look at the failures of GlobalISel specific bots >> >> For people not developing for GlobalISel, it will: >> - Increase the compile time since the GlobalISel framework and the related target specific parts will have to be built > > How long does it take to run `make check` from a clean LLVM build with and without GlobalISel enabled?I get the following numbers with `ninja check`, no additional ninja option, built with LLVM_BUILD_GLOBAL_ISEL=ON|OFF and build type=Debug|Release, all targets: * Debug builds: without GlobalISel: real 18m44.975s user 100m16.226s sys 11m41.555s llc size: 104M with GlobalISel: real 18m49.772s user 101m5.080s sys 11m49.893s llc size: 104M That’s a 5 sec difference for an almost 19min build and an end result binary of the same size (`du -sh`). * Release builds: without GlobalISel real 13m29.681s user 86m4.347s sys 9m4.553s llc size: 36M with GlobalISel real 13m30.956s user 87m0.109s sys 9m0.999s llc size: 37M That’s roughly the same build time for both: ~13min and an end result binary ~3% bigger (1M diff) but for du -sh.> >> - Increase the size of the binary (depending on what backend you pull) > > How large is llc with only X86 and AArch64 configured in, with and without GlobalISel enabled?For X86 and AArch64 only, the overhead is similar, i.e., negligible if you ask me :): * Debug builds: without GlobalISel: real 10m34.513s user 61m37.631s sys 6m45.220s llc size: 75M with GlobalISel: real 10m32.480s user 62m43.664s sys 6m50.433s llc size: 76M That’s a 2 sec difference for a ~10min build and an end result binary ~1% bigger (1M diff) but for du -sh. * Release builds: without GlobalISel real 9m1.932s user 61m13.874s sys 5m5.297s llc size: 23M with GlobalISel real 9m13.297s user 61m59.804s sys 5m11.672s llc size: 23M That’s a 10 sec difference for a 9min build and an end result binary of the same size. The bottom line is that IMHO, this is noise. Cheers, -Quentin> > Thanks, > > Mehdi-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170117/11519e1b/attachment.html>
Quentin Colombet via llvm-dev
2017-Jan-18 04:40 UTC
[llvm-dev] RFC: Building GlobalISel by default
Hi Philip,> On Jan 13, 2017, at 9:21 PM, Philip Reames via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I would lean towards doing this, but don't have an strong opinion either way. > > Would it be possible (in another thread) to get a brief status report of where we are with GlobalISEL overall?Sure, I’ll do that. I’ll post the link when the mail is sent. Thanks, -Quentin> > Philip > > > On 01/13/2017 05:54 PM, Quentin Colombet via llvm-dev wrote: >> Hi all, >> >> Now, four backends (if I am counting right: X86, ARM, AArch64, AMDGPU) are working on bringing-up GlobalISel, I’d like to switch the default of the LLVM_BUILD_GLOBAL_ISEL variable in CMake, such that the framework gets built by default. >> >> ** Impact of Flipping the Switch ** >> >> * Upsides * >> >> For people developing on GlobalISel, it will: >> - Simplify the CMake command to type :) >> - Build/Test GlobalISel on all the LLVM bots >> >> For people not developing on GlobalISel, it will: >> - Test that GlobalISel still works with your changes (make check will test that for you) >> - Allow you to play with it! >> >> Basically flipping the default CMake setting will give access to all the ISel schemes that we have in LLVM, instead of just SDISel and FastISel. >> >> * Downsides * >> >> For people developing on GlobalISel, it will: >> - Leave the status as it is now, meaning that mainly only people working on GlobalISel look at the failures of GlobalISel specific bots >> >> For people not developing for GlobalISel, it will: >> - Increase the compile time since the GlobalISel framework and the related target specific parts will have to be built >> - Increase the size of the binary (depending on what backend you pull) >> - Require the setting of an additional CMake variable to disable it (-DLLVM_BUILD_GLOBAL_ISEL=OFF) >> >> >> What do people think? >> >> Thanks, >> -Quentin >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Tom Stellard via llvm-dev
2017-Jan-23 16:04 UTC
[llvm-dev] RFC: Building GlobalISel by default
On Fri, Jan 13, 2017 at 05:54:15PM -0800, Quentin Colombet via llvm-dev wrote:> Hi all, > > Now, four backends (if I am counting right: X86, ARM, AArch64, AMDGPU) are working on bringing-up GlobalISel, I’d like to switch the default of the LLVM_BUILD_GLOBAL_ISEL variable in CMake, such that the framework gets built by default. > > ** Impact of Flipping the Switch ** > > * Upsides * > > For people developing on GlobalISel, it will: > - Simplify the CMake command to type :) > - Build/Test GlobalISel on all the LLVM bots > > For people not developing on GlobalISel, it will: > - Test that GlobalISel still works with your changes (make check will test that for you) > - Allow you to play with it! > > Basically flipping the default CMake setting will give access to all the ISel schemes that we have in LLVM, instead of just SDISel and FastISel. > > * Downsides * > > For people developing on GlobalISel, it will: > - Leave the status as it is now, meaning that mainly only people working on GlobalISel look at the failures of GlobalISel specific bots > > For people not developing for GlobalISel, it will: > - Increase the compile time since the GlobalISel framework and the related target specific parts will have to be built > - Increase the size of the binary (depending on what backend you pull) > - Require the setting of an additional CMake variable to disable it (-DLLVM_BUILD_GLOBAL_ISEL=OFF) > > > What do people think? >I would like to see this built by default it makes it easier for users using PPAs or other bleeding edge package repositories to test GlobalISel. -Tom> Thanks, > -Quentin > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Gerolf Hoflehner via llvm-dev
2017-Jan-25 01:07 UTC
[llvm-dev] RFC: Building GlobalISel by default
+1 I think all concern have been addressed. At most there could be minor hiccups that will be dealt with quickly. -Gerolf> On Jan 23, 2017, at 8:04 AM, Tom Stellard via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Fri, Jan 13, 2017 at 05:54:15PM -0800, Quentin Colombet via llvm-dev wrote: >> Hi all, >> >> Now, four backends (if I am counting right: X86, ARM, AArch64, AMDGPU) are working on bringing-up GlobalISel, I’d like to switch the default of the LLVM_BUILD_GLOBAL_ISEL variable in CMake, such that the framework gets built by default. >> >> ** Impact of Flipping the Switch ** >> >> * Upsides * >> >> For people developing on GlobalISel, it will: >> - Simplify the CMake command to type :) >> - Build/Test GlobalISel on all the LLVM bots >> >> For people not developing on GlobalISel, it will: >> - Test that GlobalISel still works with your changes (make check will test that for you) >> - Allow you to play with it! >> >> Basically flipping the default CMake setting will give access to all the ISel schemes that we have in LLVM, instead of just SDISel and FastISel. >> >> * Downsides * >> >> For people developing on GlobalISel, it will: >> - Leave the status as it is now, meaning that mainly only people working on GlobalISel look at the failures of GlobalISel specific bots >> >> For people not developing for GlobalISel, it will: >> - Increase the compile time since the GlobalISel framework and the related target specific parts will have to be built >> - Increase the size of the binary (depending on what backend you pull) >> - Require the setting of an additional CMake variable to disable it (-DLLVM_BUILD_GLOBAL_ISEL=OFF) >> >> >> What do people think? >> > > I would like to see this built by default it makes it easier for users > using PPAs or other bleeding edge package repositories to test > GlobalISel. > > -Tom > >> Thanks, >> -Quentin >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev> > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://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/20170124/566ea36e/attachment.html>