[LLVMdev] Controlling order of instructions

Sergey Dmitrouk sdmitrouk at accesssoftek.com
Fri Jul 18 05:29:55 PDT 2014


Hi,

I'm trying to improve performance of code generated for AArch64, as
described in this thread [0] about memcpy() inlining, and have two issues
with it:

1) Some output sequences look like this:
     ...something...
     load
     ...something...
     store
     load
     store
   By chaining each next load with previous store I can turn it into:
     ...something...
     ...something...
     load
     store
     load
     store
   It can be done directly in SelectionDAG.cpp, but it's target-specific
   and shouldn't go there.  If I make it target-specific, it never gets
   called, because SelectionDAG uses the following sequence of calls:
    1. Try generic load&store generator.
    2. Try target-specific load&store generator.
    3. Try generic load&store generator and force generation.

   My question is how can I give target-specific generator bigger
   priority in this case?  Is there any flag for this, or maybe it's worth
   adding one?

2) Second issue seems to be harder, I'd like to prevent Machine Instruction
   Scheduler from reordering
     load
     store
     load
     store
   into
     load
     load
     store
     store
   Chaining and specifying IROrder doesn't help (assuming I implement it
   correctly).  I don't see particular order on picking instructions
   in GenericScheduler that don't really depend on each other.  Reordering
   seems to occur as a side effect of something else.  If there are more
   load&store operations (e.g. four pairs of load&store), only the last
   four instructions are reordered.

   I don't see how scheduling can be controlled other than by providing
   custom scheduler, but will it help?  I do not see enough ordering
   information at this level and don't understand how it can be forced.

Can somebody advice me on this?  If it's documented somewhere and I miss
that, you could just give me a link.

Thanks,
Sergey

[0]: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140714/226044.html



More information about the llvm-dev mailing list