Jan Hubicka <hubi...@ucw.cz> writes: > > libcall is not faster up to 8KB to rep sequence that is better for > regalloc/code > cache than fully blowin function call.
I noticed btw that some of the generated string instructions are slower than just calling the C library. rep scasb etc. is rarely a win over an optimized library function, it's not very optimized. Perhaps those patterns should just be disabled. The way to optimize that on modern CPUs is to use PCMP*STR*, but that's quite a bit more complicated and has some constraints. >> > /* X86_TUNE_FOUR_JUMP_LIMIT: Some CPU cores are not able to predict more >> > than 4 branch instructions in the 16 byte window. */ >> > - m_PPRO | m_P4_NOCONA | m_CORE2I7 | m_ATOM | m_AMD_MULTIPLE | m_GENERIC, >> > + m_PPRO | m_P4_NOCONA | m_ATOM | m_AMD_MULTIPLE | m_GENERIC, > > This is special passs to handle limitations of AMD's K7/K8/K10 branch > prediction. > Intel never had similar design, so this flag is pointless. Actually the Sandy Bridge decoded icache has a limit of 3 jumps per 16 byte window. If you exceed that it falls back to running the full decoder from the normal icache. I don't have solid data, but it may be a win for frontend limited code (otherwise possibly more in power than performance) I would revisit that for Sandy Bridge -Andi -- a...@linux.intel.com -- Speaking for myself only
