[llvm-commits] [llvm] r139765 - in /llvm/trunk: include/llvm/CodeGen/LiveInterval.h lib/CodeGen/RegisterCoalescer.cpp test/CodeGen/X86/2011-09-14-valcoalesce.ll

[Andrew Trick]

On Sep 15, 2011, at 9:32 AM, Jakob Stoklund Olesen wrote:

> 
> On Sep 15, 2011, at 9:19 AM, Andrew Trick wrote:
> 
>> On Sep 14, 2011, at 7:46 PM, Jakob Stoklund Olesen wrote:
>> 
>>> 
>>> How would this test actually fail? The miscompilation didn't cause llc to crash, right?
>> 
>> Nope. And verification does catch it. We really need post-coalescing interference verification based on SSA values.
> 
> That would be nice, but we would need to refer back to the LLVM IR values.  In this case, the coalescer was actively editing the code to put the wrong value be wrong.  Everything looks OK after coalescing, unless you compare against some side-table.

Not LLVM IR values, just the original singly defined vreg names. This sort of verification is easy if you don't rewrite any operands until after coalescing and verification. You're right, performing phi elimination, then rewriting copies on-the-fly as this optimization does defeats verification. Ideally, the optimization would not be done this way. It's not something we can seriously consider now, but it's good to bring up when we hit these sort of bugs.

>> I struggled with how to add CHECK lines that weren't ridiculously fragile.
> 
> Yep, known problem.
> 
>> Block's are "randomly" shuffled
> 
> -disable-branch-fold helps.
> 
>> , copies "randomly" coalesced on different paths, and registers "randomly" renamed. I can try to add some though if you think it's worthwhile.
> 
> Just a simple CHECK that a copy is inserted in the desired block.
> 
> I know this depends on coalescing order, but that is quite stable.


By "randomly" I meant stable run-to-run but changing every time I further reduced the test. I'm working on a better test case.

-Andy