[PATCH] D14971: X86: Emit smaller code for moving 8-bit immediates

Hans Wennborg via llvm-commits llvm-commits at lists.llvm.org
Wed Dec 9 13:28:59 PST 2015


hans updated this revision to Diff 42330.
hans added a comment.

Follow-up from the previous patch:

joerg pointed out on IRC that we should definitely do push-pop for minsize (I agree), and maybe also at optsize for all values that are not -1 and 1 (I don't have a strong opinion yet).

majnemer wondered if the clobbering of EFLAGS was properly tracked. I believe it was: the pattern expands to instructions that declare this dependence; the pattern shouldn't (can't) declare that itself. He also expressed concern that we're increasing the pressure on the EFLAGS. That's true, but I don't think it's a big problem in practice.

A serious problem with the previous patch is that it broke re-materialization. To handle that, I think we have to use pseudo instructions. My new patch does that.

I also realized that the size trade-offs are more complex in 64-bit mode. For example, xor-inc takes 4 bytes there, but 6 bytes if REX-prefixed. That means it's not profitable for registers that need REX (except 64-bit -1). I could use the GR32_NOREX register class on the pseudo instructions, but (I think) that means we'd no longer be able to materialize these constants in REX registers. We could also make the pseudo expand to different things depending on register class, but then it's getting iffy.

And, in 64-bit mode, 32-bit "or -1" and 64-bit push-pop are still only 3 bytes (4 bytes with REX), so shorter than xor-inc -- maybe we should use one of them instead?

To get this patch moving, I would like to punt on the 64-bit issue and just do the 32-bit 1 and -1. What do you think?


http://reviews.llvm.org/D14971

Files:
  lib/Target/X86/X86InstrCompiler.td
  lib/Target/X86/X86InstrInfo.cpp
  test/CodeGen/X86/materialize-one.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D14971.42330.patch
Type: text/x-patch
Size: 5328 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20151209/78eb7f44/attachment.bin>


More information about the llvm-commits mailing list