[PATCH] [AArch64] Load Balancing for AES instructions on Cortex-A57

James Molloy james.molloy at arm.com
Tue Nov 11 02:40:20 PST 2014


Hi Zhao,

There are some subtleties here that I don't think you're handling correctly. The major one is tied operands, which are not handled right and are the reason I removed handling of MLAv2f32 from this pass.

Consider a chain where the end instruction is the same as the kill instruction (which means the end dest register cannot be changed). The fixup code currently will look at the last instruction and see something like:

    %D0<def,tied0> = AES... %D0<kill,tied0>, %D1...

It will look at the uses first, totally ignore the tied constraint and change %D0 to be whatever the chain register is. It will then not look at the def, because it knows it is illegal to change the def. We then have a broken instruction.

When you add proper handling for this (along with a decent amount of tests, because this is incredibly fiddly to get right), we can re-add support for MLAv2f32. Which would be nice :)

Secondly I think your algorithm is going the wrong way. It is chaining the instructions going forward through the instruction stream instead of backwards. Consider, it's possible that we can't change the dest operand of the last instruction in the chain. As the operand is tied, the accumulator has to be the same as the dest. So choosing the chaining register as the dest of the last instruction seems the right thing to do. Currently your algorithm could get to the last instruction and not be able to change it. If you implement this algorithm, you actually don't need to handle tied operands specially (although I still would like to see proper assertions in place that they're not corrupted), because you never get to the situation where you can change an accum but not a dest.

Thirdly, are AES instruction statically scheduled by the core? My belief is "no", which is fine, but they should not contribute to the computed static parity. If "yes", then they should probably be sorted to appear in the ready queue before FMADDs.

Cheers,

James

http://reviews.llvm.org/D6154






More information about the llvm-commits mailing list