Odd Loop x86 CodeGen Behavior

[Vladimir Kozlov]

Ed,

The next parts of code are generated for MachSpillCopy mach nodes:

090   	MOV    EAX,[ESP + #64]
	MOV    EDX,[ESP + #68]

0dd   B7: #	B8 <- B2  Freq: 0.0579261
0dd   	MOV    EAX,[ESP + #64]
	MOV    EDX,[ESP + #68]

0ec   B9: #	B2 <- B8  Freq: 0.087028
0ec   	MOV    [ESP + #64],EAX
	MOV    [ESP + #68],EDX

MachSpillCopy nodes for the last 2 (at the address dd and ec)
should be eliminated at least in post_allocate_copy_removal().
Could you look why it is not happening?
Pay more attention to the code guarded by !is_single_register()
method.

Thanks,
Vladimir


Edward Lee wrote:
> On Wed, Dec 10, 2008 at 12:29 AM, Edward Lee <edilee at gmail.com> wrote:
>> I've attached the original output...
> To help figure out what the ideal graph/x86 is doing, I've
> "hand-disassembled" to the resulting inlined/magic high level, which
> should be something similar to..
> 
> BasePage FileContainer::getUserPage(BaseContainerHandle a0,
>     long pageNumber, boolean a2, boolean a3) {
> 
>   Entry[] table = this.pageCache.cache_.table;
> 
>   int hash = (int) (this.identity.containerId ^ this.identity.segmentId);
>   hash = (int) ((long) hash ^ pageNumber);
>   hash = hash ^ (hash >>> 20) ^ (hash >>> 12);
>   hash = hash ^ (hash >>> 7) ^ (hash >>> 4);
> 
>   Entry<PageKey, CachedItem> entry = table[hash & table.length - 1];
>   while (entry != null) {
>     if (entry.hash == hash && entry.key.pageNumber == pageNumber)
>       break;
>     entry = entry.next;
>   }
> 
>   this.pageCache.stat.findHit++;
>   entry.value.recentlyUsed_ = true;
>   entry.value.keepCount++;
> 
>   this.latchPage(a0, entry.value.entry, a3);
> 
>   return entry.value.entry;
> }
> 
> Ed