[PATCH] [RFC] Lame fix for PR20376

Peter Collingbourne peter at pcc.me.uk
Tue Jul 29 12:09:14 PDT 2014


On Tue, Jul 22, 2014 at 10:26:29AM +0000, Tim Northover wrote:
> We actually do have a last-ditch EFLAGS copy available (though with worrying implications for the red-zone, if we ever start using it). It's used by test/CodeGen/Generic/2011-07-07-ScheduleDAGCrash.ll for example.
> 
> Enabling it more generally is probably just a matter of tweaking getCopyCost. Which might be an idea for robustness anyway.

Okay, I've tried modifying the copy cost of EFLAGS (see attached). I also
needed to create a register class for GR32+EFLAGS in order to try to avoid
the large number of EFLAGS copies I was seeing. This wasn't enough; I was
still seeing plenty of copies (and segfaults while bootstrapping). I'm not
sure if debugging this will send me down an even larger rabbit hole.

> But I'm not sure that actually affects the best solution here. I rather suspect performing the comparison again would be quicker in general. I suppose the question is how common and performance-critical such fragments are.

At this point I'm inclined to work on performing the comparison again
(unconditionally). From your other messages I gather this would be a revert
of an earlier commit (r210923)? I guess we could consider peephole-removing
the extra compare where possible, but I don't have a sense of how important
this would be.

Thanks,
-- 
Peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Change-the-cost-of-EFLAGS-copies.patch
Type: text/x-diff
Size: 4994 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140729/af801923/attachment.patch>


More information about the llvm-commits mailing list