[llvm] r231186 - RegisterCoalescer: Gracefully continue if subrange merging fails.

[Quentin Colombet]

> On Mar 3, 2015, at 6:32 PM, Hal Finkel <hfinkel at anl.gov> wrote:
> 
> ----- Original Message -----
>> From: "Chandler Carruth" <chandlerc at google.com>
>> To: "Quentin Colombet" <qcolombet at apple.com>
>> Cc: "Commit Messages and Patches for LLVM" <llvm-commits at cs.uiuc.edu>, "Matthias Braun" <matze at braunis.de>
>> Sent: Tuesday, March 3, 2015 7:54:30 PM
>> Subject: Re: [llvm] r231186 - RegisterCoalescer: Gracefully continue if	subrange merging fails.
>> 
>> 
>> 
>> Thanks both Quentin and Matthias.
>> 
>> 
>> Two completely meta points:
>> 
>> 
>> 1) It'd be useful to mention this in a commit that obviously has no
>> test case. Saves a round trip checking whether it just was
>> accidentally left off the commit.
>> 
>> 
>> 2) This makes me want to encourage thinking about ways to unittest
>> components of CodeGen in the future. Historically we haven't looked
>> at that, but if we need to support and debug out-of-tree targets
>> with interesting properties like this it may became important to
>> grow that ability. Its an important use case for these libraries to
>> work even with wildly different targets, and important that folks
>> can check that they're handling edge cases without access to all the
>> weird targets in the world. =]
>> 
> 
> I'd like to encourage this independent of the use case of out-of-tree targets. We have a serious problem with testing of CodeGen components, generally; we currently construct IR-level tests, but this is very fragile. Many of the IR-level CodeGen tests, especially "bug-triggering" regression tests, don't currently test the logic they were originally designed to cover.

Agreed.

Could this be a proposal for a GSoC?

Q.

> 
> -Hal
> 
>> 
>> Anyways, thanks for explaining.
>> 
>> 
>> On Tue, Mar 3, 2015 at 5:29 PM, Quentin Colombet <
>> qcolombet at apple.com > wrote:
>> 
>> 
>> 
>> With the in-tree target this not exposed.
>> 
>> 
>> Arguably we could create a fake target with such problem, but I do
>> not think this is worth the complexity.
>> 
>> 
>> Q.
>> 
>> 
>> 
>> 
>> 
>> On Mar 3, 2015, at 5:21 PM, Chandler Carruth < chandlerc at google.com >
>> wrote:
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> On Tue, Mar 3, 2015 at 4:43 PM, Matthias Braun < matze at braunis.de >
>> wrote:
>> 
>> 
>> 
>> Author: matze
>> Date: Tue Mar 3 18:43:50 2015
>> New Revision: 231186
>> 
>> URL: http://llvm.org/viewvc/llvm-project?rev=231186&view=rev
>> Log:
>> RegisterCoalescer: Gracefully continue if subrange merging fails.
>> 
>> There is a known bug where the register coalescer fails to merge
>> subranges when multiple ranges end up in the "overflow" bit 32 of the
>> lanemasks. A proper fix for this is complicated so for now this is a
>> workaround which lets the register coalescer drop the subregister
>> liveness information (we just loose some precision by that) and
>> continue.
>> 
>> Modified:
>> llvm/trunk/lib/CodeGen/RegisterCoalescer.cpp
>> No test case? This seems like something really important to cover...
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>> 
>> 
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu <mailto:llvm-commits at cs.uiuc.edu>
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits <http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits>
>> 
> 
> -- 
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150304/dcdb5985/attachment.html>