[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