During remat, some subranges might end up having invalid segments which caused problems for later
coalescing.
Added in a check to remove segments that are invalidated as part of the remat.
Differential D34391
[RegisterCoalescer] Fix for SubRange join unreachable dstuttard on Jun 20 2017, 2:25 AM. Authored by
Details During remat, some subranges might end up having invalid segments which caused problems for later Added in a check to remove segments that are invalidated as part of the remat.
Diff Detail
Event TimelineComment Actions I've added this change specifically to address a problem seen in the associated PR (http://llvm.org/PR33524), however I'm not sure that this is necessarily the right way to go about fixing this issue. I think that the remat results in an incorrect segment in the SubRange - which looks something like [128r, 128d) and is also an undef - and removing it does clear up the problem. (Prior to the remat the segment in the SubRange is correct, albeit for an undef). Comment Actions There's an example that provokes the problem in the bugzilla http://llvm.org/PR33524. I guess at this stage I'm looking for some indication whether this is a reasonable fix for the problem - before submission I'll tidy up the reproducer in the bugzilla and add as a test case.
Comment Actions Removing debug comment
Comment Actions Updating the test as per review comments I've left it as a .ll test rather than .mir as the mir print routines can't cope "TargetCustom pseudo source values are not supported" Comment Actions FYI I tried this patch in my out-of-tree backend (hoping to resolve http://llvm.org/PR32773). I observed a segfault SR.removeValNo(RmValNo) because RmValNo may be null. I don't know yet whether this is specific to my backend, but I thought I'd mention it in case it indicates a more general problem. Comment Actions Doh = forgot the check for null. I'll upload a change for this. Comment Actions Thanks for working on this! A bunch of nitpicks are below but overal the fix looks fine.
Comment Actions Updating in line with comments from reviewers I haven't updated the test to .mir as I don't fully understand what Comment Actions The TargetCustom error is from the pseudo value source used for the buffer intrinsics memory operands. If you remove those you should avoid the error. Also it may still reproduce if you replace the intrinsics in the IR with volatile loads Comment Actions The code fix LGTM, but please wait for @qcolombet/@arsenm before committing. Making a .mir test seems indeed hard at the moment, as the printer already fails; manually stripping memory operands only works after printing I presume? Comment Actions Yes, stripping the operands only works after printing :( @arsenm I'll try using volatile loads and stores to see if that works in this case. Would it be acceptable in the meantime to accept this change and then I'll update the .ll test with a .mir one when it works? Comment Actions Updating the test to a .mir test |