[LLVMdev] Advices Required: Best practice to share logic between DAG combine and target lowering?

Quentin Colombet qcolombet at apple.com
Mon Jul 1 12:07:46 PDT 2013


On Jul 1, 2013, at 11:52 AM, Eli Friedman <eli.friedman at gmail.com> wrote:

> On Mon, Jul 1, 2013 at 11:30 AM, Quentin Colombet <qcolombet at apple.com> wrote:
> Hi,
> 
> ** Problematic **
> I am looking for advices to share some logic between DAG combine and target lowering.
> 
> Basically, I need to know if a bitcast that is about to be inserted during target specific isel lowering will be eliminated during DAG combine.
> 
> Let me know if there is another, better supported, approach for this kind of problems.
> 
> ** Motivating Example **
> The motivating example comes form the lowering of vector code on armv7.
> More specifically, the build_vector node is lowered to a target specific ARMISD::build_vector where all the parameters are bitcasted to floating point types.
> 
> This works well, unless the inserted bitcasts survive until instruction selection. In that case, they incur moves between integer unit and floating point unit that may result in inefficient code.
> 
> Attached motivating_example.ll shows such a case:
> llc -O3 -mtriple thumbv7-apple-ios3 motivating_example.ll -o -
> 	ldr	r0, [r1]
> 	ldr	r1, [r2]
> 	vmov	s1, r1
> 	vmov	s0, r0
> Here each ldr, vmov sequences could have been replaced by a simple vld1.32.
> 
> ** Proposed Solution **
> Lower to more vector friendly code (using a sequence of insert_vector_elt), when bit casts will not be free.
> The attached patch demonstrates that, but is missing the proper check to know what DAG combine will do (see TODO).
> 
> I think you're approaching this backwards: the obvious thing to do is to generate the insert_vector_elt sequence unconditionally, and DAGCombine that sequence to a build_vector when appropriate.
Thanks Eli.

I will try that approach.

-Quentin

> 
> -Eli

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130701/33178708/attachment.html>


More information about the llvm-dev mailing list