[PATCH] D44838: [X86] Correct the placement of ReadAfterLd in BEXTR and BZHI

[Andrea Di Biagio via Phabricator via llvm-commits]

andreadb added a comment.

In https://reviews.llvm.org/D44838#1052205, @craig.topper wrote:

> So basically the Intel per instruction overrides have broken every instruction with a folded load because we lost the ReadAfterLd on all of them?
>
> For example
>  [0,0]   DeER .   .      addl    %edi, %esi
>  [0,1]   D=eeeeeeER      addl    (%rdi), %esi


Looks like it... Sounds scary.

I just tried that same code snippet.
For btver2 I get the expected result:

  Index   0123456
  
  [0,0]   DeER .. addl    %edi, %esi
  [0,1]   DeeeeER addl    (%rdi), %esi
  `

Unfortunately I don't get the correct ReadAdvance on Haswell (I get the same output that you posted).

On Haswell, the SchedClassID for the add with the folded memory operand is #912.
According to X86GenSubtargetInfo.inc

  {DBGFIELD("ADD16rm_ADD32rm_ADD64rm_ADD8rm_AND16rm_AND32rm_AND64rm_AND8rm_CMP16mi_CMP16mi8_CMP32mi_CMP32mi8_CMP64mi32_CMP64mi8_CMP8mi_CMP8mi8_CMP16mr_CMP32mr_CMP64mr_CMP8mr_CMP16rm_CMP32rm_CMP64rm_CMP8rm_OR16rm_OR32rm_OR64rm_OR8rm_SUB16rm_SUB32rm_SUB64rm_SUB8rm_TEST16mr_TEST32mr_TEST64mr_TEST8mr_TEST16mi_TEST32mi_TEST64mi32_TEST8mi_XOR16rm_XOR32rm_XOR64rm_XOR8rm") 2, false, false, 12, 4,  3, 1,  0, 0}, // #912

The last two numbers are respectively the "ReadAdvanceIdx", and the number of read-advance entries. Both are zero for Haswell, which means we lost that information.
Basically, all the instructions that use HWWriteResGroup18 had lost the ReadAdvance info.


https://reviews.llvm.org/D44838