- candorParticipantSeptember 14, 2017 at 6:36 pmPost count: 1
The paper is called “Clairvoyance: Look-Ahead Compile-Time Scheduling” and it was published early this year. You can get a full text copy at http://urn.kb.se/resolve?urn=urn:nbn:se:uu:diva-316480 and they have code available at https://github.com/ktran/clairvoyance .
I thought it looked applicable to the compiler work done for the Mill since the Mill doesn’t have an instruction window to look ahead for future reads in like an out of order machine and in the Mill presentations hoisting loads was mentioned. They were able to get performance and energy efficiency improvements on some benchmarks when testing on an APM X-Gene processor (server ARM chip). Architecture differences mean that on the Mill pointer aliasing is less of a concern and speculatively violating memory protection isn’t a concern. Also, instead of register pressure you have load retire station pressure.
- Ivan GodardKeymasterSeptember 15, 2017 at 12:34 amPost count: 607
An interesting paper, but of limited relevance to the Mill. Because (as you note) both aliasing and protection checks are not an issue for us, we can in general hoist a load to any point after the address is available, and can often hoist (much of) the address computation too.
Of the issues listed in the paper:
1) Finding enough independent instructions: always an issue on the higher end members, even when being liberal with speculation. Hoisting helps somewhat, but there’s no point in hoisting just to introduce no-ops.
2) Chains of long-latency instructions: This is a restate of #1, because if there are plenty of independent instructions then long chains are hatmless.
3) Increased register (retire station) pressure: this is a lesser issue on the Mill because we don’t unroll.
So while the paper addresses some of the same things that the Mill architecture does, the methods used have costs that are obviated on the Mill.I doubt that combining the two would give any net benefit.
You must be logged in to reply to this topic.