[llvm-dev] RFC: Building GlobalISel by default
Quentin Colombet via llvm-dev
llvm-dev at lists.llvm.org
Tue Jan 17 20:39:58 PST 2017
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>
More information about the llvm-dev
mailing list