[llvm] r190717 - Adds support for Atom Silvermont (SLM) - -march=slm

Hello Andy,

Thank you for your offer to work together on implementing the your new scheduler on X86. I can start working on this right away.

In case you were unaware, the new Silvermont micro-architecture is only out of order on the integer side. The SSE instructions are still in order, so the current postRA scheduler is very beneficial for code with lots of SSE instructions, such as the ISPC (http://ispc.github.io) (example programs. Hence I would be looking at re-implementing the schedulers for both Atom and Silvermont.

In the meantime, I would appreciate it if the current PostRA scheduler could be kept in place until such time as we can prove that the new scheduler is at least as good as what we have now.

It is also considered around here that it is desirable that the new scheduler be made to run after register allocation is done, as has already been discussed in LLVMDev.

Please let me know what the next step should be.

Preston

Hello Andy,

Thank you for your offer to work together on implementing the your new scheduler on X86. I can start working on this right away.

In case you were unaware, the new Silvermont micro-architecture is only out of order on the integer side. The SSE instructions are still in order, so the current postRA scheduler is very beneficial for code with lots of SSE instructions, such as the ISPC (http://ispc.github.io) (example programs. Hence I would be looking at re-implementing the schedulers for both Atom and Silvermont.

No problem. We support this model for cortex-a9.

In the meantime, I would appreciate it if the current PostRA scheduler could be kept in place until such time as we can prove that the new scheduler is at least as good as what we have now.

Yes.

It is also considered around here that it is desirable that the new scheduler be made to run after register allocation is done, as has already been discussed in LLVMDev.

Please let me know what the next step should be.

The next steps for me (in my spare time) are:

  • Enable a post-RA MachineScheduler pass
  • Add support to GenericScheduler for in-order pipeline using the new machine model (easier than it sounds)

The next step for you is to look at the SandyBridge/Haswell machine models as an example of how to define an X86 model.

Also look at the new model in ARMScheduleA9.td, that’s all lines after

  • // ===---------------------------------------------------------------------===//
  • // The following definitions describe the simpler per-operand machine model.

It is an example of an in-order/out-of-order mix. The relevant line is this:

def A9UnitFP : ProcResource<1> { let BufferSize = 0; }

A9 is also an example of piggybacking on existing itinerary classes. This is an option for bringing up a new model, but it would be better to use the SchedRW lists like SandyBridge. That way, we could eventually simplify the instruction definitions by removing all the itinerary classes.

If you find something confusing, just ask. If you have an idea how to migrate Atom, you can send me a sample of what you have in mind and I’ll comment before you jump into rewriting everything. We can work through this off list.

Thanks for your time!

-Andy