> 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.
This is only about memset/memcpy expanding. The other sequences are quite lame indeed... > > > >> > /* 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 We are not particularly good on avoiding the branches - basically the code inserts alignment whenever it things the 4 consecutive branches fit in the window. I can make patch to change this to 3 and we can see if it helps at all. > > -Andi > -- > a...@linux.intel.com -- Speaking for myself only