[llvm-dev] RFC: Building GlobalISel by default

[Quentin Colombet via llvm-dev]

> On Jan 19, 2017, at 1:10 PM, Jim Grosbach <grosbach at apple.com> wrote:
> 
>> 
>> On Jan 19, 2017, at 11:59 AM, Quentin Colombet <qcolombet at apple.com <mailto:qcolombet at apple.com>> wrote:
>> 
>> Hi all,
>> 
>> Trying to summarize the concerns along side my answers but I believe we are good to do the switch to build GlobalISel by default. In particular, Renato and I exchanged offline and he tried doing the switch on some of the bots he maintained and did not see any overhead/problem for that.
>> Let me know if you disagree.
>> 
>> 
>> * What is the impact on compile time?
>> 
>> Negligible: ~5s for a 19min build. (See http://lists.llvm.org/pipermail/llvm-dev/2017-January/109185.html <http://lists.llvm.org/pipermail/llvm-dev/2017-January/109185.html> for the details.)
>> 
>> 
>> * What is the impact on binary size?
>> 
>> Negligible: 0 to 1M on a 37M to 104M. (See http://lists.llvm.org/pipermail/llvm-dev/2017-January/109185.html <http://lists.llvm.org/pipermail/llvm-dev/2017-January/109185.html> for the details.)
>> 
>> 
>> * How likely GlobalISel will break on non-related change?
>> 
>> Unlikely: GlobalISel's APIs are fairly isolated or work on pretty well established low-level APIs. (See http://lists.llvm.org/pipermail/llvm-dev/2017-January/109154.html <http://lists.llvm.org/pipermail/llvm-dev/2017-January/109154.html> for details.)
>> 
>> 
>> * Why GlobalISel wasn’t built from the start?
>> 
>> One of the requirement was that we don’t impact negatively the footprint of the compiler. Given we were not sure where we were going and in particular we temporarily increased the size of the MachineInstrs and some other core classes during the prototype, we decided to turn it off by default. Those problems have been fixed now.
>> 
>> 
>> * How is the existing GlobalISel implement viewed?
>> 
>> Last year we finished the proof-of-concept and are moving toward production quality now. We are doing reviews like any other part of the code and rewrite what we believe needs to be rewritten. I’ll go into more details regarding the status in another thread, but one of the thing we are pushing right now is tablegen support in GlobalISel so that we can just reuse the existing td form SDISel.
> 
> To reinforce Quentin’s point here, if folks have concerns about the suitability of areas of the code for long term maintainability, elegance of design or implementation, or anything else regarding the code quality, please say so. Deep and thorough review is essential to long term success.

+1, well say!

> 
>> 
>> 
>> Let me know if I didn’t address some of the concerns.
>> 
>> Cheers,
>> -Quentin
[...]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170119/87cb18cd/attachment.html>