llvm dev - Jan 2017 - 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

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>

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?
> - 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

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

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 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.

> 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

> 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

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>

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

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>

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>

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>

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

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

+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>