On 7 November 2013 20:01, Uros Bizjak <ubiz...@gmail.com> wrote: > OTOH, looking a bit deeper, it looks that there is a problem in > mode-switching infrastructure. If we have a BB without any mode > requirements, but an insn that switched the mode via MODE_AFTER, we > should not mark the block as transparent. Indeed, we even have a N.B. > comment in mode-switching.c: > > /* Check for blocks without ANY mode requirements. > N.B. because of MODE_AFTER, last_mode might still be different > from no_mode. */ > > But, we do nothing w.r.t to transparency
The optimize_mode_switching patch makes sense to me. > Attached incremental patch also fixes additional vzeroupper problem. > Calls with AVX argument register in fact do not have any mode > requirements, so we don't need to fake MODE_DIRTY requirement. Not sure about this - because I'm note sure what the meaning of values in avx_u128_state are. This lack of clarity is not caused by your patch, but is that something that could be reasonably be explained in a comment, or would that have to be too long to be helpful?
