[PATCH] [CodeGenPrepare] Move extractelement close to store if they can be combined.

[Quentin Colombet]

Hi hfinkel,

Hi,

This patch adds an optimization in CodeGenPrepare to move an extractelement right before a store when the target can combine them.
The optimization may promote any scalar operations to vector operations in the way to make that possible.

Thanks for your feedbacks.


** Context **

Some targets use different register files for both vector and scalar operations. This means that transitioning from one domain to another may incur copy from one register file to another. These copies are not coalescable and may be expensive.
For example, according to the scheduling model, on cortex-A8 a vector to GPR move is 20 cycles.


** Motivating Example **

Let us consider an example:
define void @foo(<2 x i32>* %addr1, i32* %dest) {
  %in1 = load <2 x i32>* %addr1, align 8
  %extract = extractelement <2 x i32> %in1, i32 1
  %out = or i32 %extract, 1
  store i32 %out, i32* %dest, align 4
  ret void
}

As it is, this IR generates the following assembly on armv7:
	vldr	d16, [r0]            @vector load  
	vmov.32	r0, d16[1]  @ cross-register-file copy: 20 cycles
	orr	r0, r0, #1           @ scalar bitwise or
	str	r0, [r1]               @ scalar store
	bx	lr

Whereas we could generate much faster code:
	vldr	d16, [r0]               @ vector load
	vorr.i32	d16, #0x1     @ vector bitwise or
	vst1.32	{d16[1]}, [r1:32] @ vector extract + store
	bx	lr

Half of the computation made in the vector is useless, but this allows to get rid of the expensive cross-register-file copy.


** Proposed Solution **

To avoid this cross-register-copy penalty, we promote the scalar operations to vector operations. The penalty will be removed if we manage to promote the whole chain of computation in the vector domain.
Currently, we do that only when the chain of computation ends by a store and the target is able to combine an extract with a store.

Stores are the most likely candidates, because other instructions produce values that would need to be promoted and so, extracted as some point[1]. Moreover, this is customary that targets feature stores that perform a vector extract (see AArch64 and X86 for instance).

The proposed implementation relies on the TargetTransformInfo to decide whether or not it is beneficial to promote a chain of computation in the vector domain. Unfortunately, this interface is rather inaccurate for this level of details and although this optimization may be beneficial for X86 and AArch64, the inaccuracy will lead to the optimization being too aggressive.
Basically in TargetTransformInfo, everything that is legal has a cost of 1, whereas, even if a vector type is legal, usually a vector operation is slightly more expensive than its scalar counterpart. That will lead to too many promotions that may not be counter balanced by the saving of the cross-register-file copy. For instance, on AArch64 this penalty is just 4 cycles.

For now, the optimization is just enabled for ARM prior than v8, since those processors have a larger penalty on cross-register-file copies, and the scope is limited to basic blocks. Because of these two factors, we limit the effects of the inaccuracy. Indeed, I did not want to build up a fancy cost model with block frequency and everything on top of that.

[1] We can imagine targets that can combine an extractelement with  other instructions than just stores. If we want to go into that direction, the current interfaces must be augmented and, moreover, I think this becomes a global isel problem. 

Thanks,
-Quentin

http://reviews.llvm.org/D5921

Files:
  include/llvm/Target/TargetLowering.h
  lib/CodeGen/CodeGenPrepare.cpp
  lib/CodeGen/TargetLoweringBase.cpp
  lib/Target/ARM/ARMISelLowering.cpp
  test/CodeGen/ARM/vector-promotion.ll
-------------- next part --------------
A non-text attachment was scrubbed...
Name: D5921.15279.patch
Type: text/x-patch
Size: 21022 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141022/61b395bd/attachment.bin>