[llvm-dev] Missed optimization - spill/load generated instead of reg-to-reg move (and two other questions)

[Alex Wang via llvm-dev]

Hello all!

I was looking through the results of disassembling a heavily-used short function
in the program I'm working on, and ended up wondering why LLVM was generating
that assembly and what changes would be necessary to improve the code. I asked
on #llvm, but it seems that the people with the necessary expertise weren't
around.

Here is a condensed version of the code: https://godbolt.org/g/ec5cP7 <https://godbolt.org/g/ec5cP7>

My main question concerns assembly lines 37/38 and 59/60, where xmm0 is spilled
to the stack, only to be immediately reloaded into xmm1. Google tells me that
there is a register-to-register mov instruction for the xmmn registers, so I
found it odd that LLVM missed what looks like an easy optimization. tstellar on
#llvm pointed me towards using -debug-only=regalloc with llc to see what LLVM is
thinking (regalloc log here, since I'm not sure what's considered "too large"
for mailing lists: [0]), and it seemed to me like the load/store were
introduced separately, and llc never looked at them at the same time, and so
never realized that they could be folded. Is that what is happening? I know
little about compilers, so I wouldn't be surprised if I were wrong.

The other two questions are tangential, so please let me know if I should ask
them somewhere else.

On assembly lines 24 and 46, I think the vtable pointer for the Quad object is
being reloaded every iteration of the loop. nbjoerg on #llvm said that's due to
the possibility of placement new being used somewhere inside the called
function, which makes sense to me. Is there a way to indicate to LLVM that this
will not happen? I tried [[gnu::pure]], since the function doesn't write to
externally-visible memory, but the vtable pointer reload remained.

Finally, I'm inclined to say that this routine should be vectorizable, since
it's essentially just an accumulate, but Clang can't prove that GetLocalValue
doesn't have side effects that will affect later iterations. Is this correct,
and if so, are there any hints I can give Clang besides just manually
parallelizing it with #pragma omp or something?

I do intend on changing this loop to something a bit less messy, but it'll be
part of a larger refactoring, so it's still a ways off.

Thanks!

Alex

   [0]: https://hastebin.com/raw/oqamesahos <https://hastebin.com/raw/oqamesahos>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180227/f0f78d3f/attachment.html>