Tuesday 6th March 2012

This month's meetings

<< <  2012 / 3 >  >>
Mon Tue Wed Thu Fri Sat Sun
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31  


  • Andrew Stubbs
  • Åsa Sandahl
  • Michael Hope
  • Ramana Radhakrishnan
  • Richard Earnshaw
  • Bernd Schmidt (CodeSourcery/Mentor Graphics)


  • Review action items from last meeting
  • 64 bit neon arithmetic and register allocator.
  • Turning off peeling by default
  • AOB .

Action Items from this Meeting

  • ACTION: AS to investigate implementation possibilities, crafty, and post suggestions for debate upstream (eventually).

Action Items from Previous Meeting

  • Create blueprints for each of these cases with libav [All]
  • RAID xor routines in kernel - Can we vectorize the original C code ? [michaelh]
  • michaelh to refresh the peeling patch and get some benchmarks behave.
  • Libav benchmarking and what we use as content - (http://samplemedia.linaro.org) -


  • 64-bit ops work
    • AS: NEON not patch working perfectly, but needs work before RE approves it. All other patches have bugs that need to be ironed out.

  • Proposed Register Allocator optmization
    • AS summarized the proposal: to create a new pass (or otherwise) that can analyse the uses of pseudo registers, determine how their interactions with instruction constraints and other pseudos determines the choices of their eventual register class, and make an early recommendation of what class to choose. This would then guide the lower-subreg, split1, and maybe others passes, and allow better use of the optimizations available. It's not yet clear how this would be implemented, precisely, how early such a decision might occur, how the relative costs might be calculated, or whether the final result will be worth the effort.

    • RE proposed that such decisions could be made during the expand pass.

      • BS: not necessary before lower-subreg.

      • RE: bizarre that expand makes optimization decisions (instruction selection) without reference to register classes.

    • BS pointed out that, on A8, a sequence ending in a compare -- and thus requiring a move back to core registers -- would have to be very long indeed to make using NEON profitable.
      • AS: could we use an attribute to specify costs for alternatives to help determine when it's profitable?

      • BS: at present you can use ! or ? constraint-modifiers to discourage alternatives, but there's no other way.

      • BS is specifically interested in this concept for the C6X port. This has two register files, but they are more symmetrical, with the cost of an operation being the same in each, although transferring between the files is expensive.
    • BS: what about the web class optimization pass mentioned by Steven Bosscher, in his recent email? http://lists.linaro.org/pipermail/linaro-toolchain/2012-March/002193.html

      • RE: also, has anybody spoken to Vladimir Makarov? --- No.
    • We should take this upstream.
      • AS: yes, of course, but as a general question, or as an RFC on a proposal?
      • RE: propose general ideas -- not too much detail.
      • RE: perhaps write up an "options review document" and publish that - almost an RFC.
    • Can expand be made to do a better job?
      • Maybe expand could scan the GIMPLE first and select better options by looking ahead, instead of just going through in a linear fashion?
        • Perhaps implemented as a late tree pass that leaves hints for expand, somehow?
          • AS: certainly expand has a number of smarts, such as expand_doubleword_shifts that could be lifted out to a tree pass, if that would help. (Of course, that's not as straightforward as it sounds.)

    • AS: Is it worth the effort?
      • RE: There's always a risk of putting in a lot of effort for very little reward.
        • MH: 64-bit ops are not well represented in benchmarks.
      • RE: It could increase power consumption.
    • AS: Can we modify a benchmark to test the impact of greater NEON use? For example, it's possible to add asm inserts that force a given value into NEON registers, and thereby encourage the compiler to choose the NEON operators.

      • MH: Spec gcc benchmark does lots of 64-bit, but doesn't really have a small number of hot spots. Spec crafty probably is a better choice.

    • ACTION: AS to investigate implementation possibilities, crafty, and post suggestions for debate upstream (eventually).

WorkingGroups/ToolChain/Meetings/Archive/2012-03-06 (last modified 2013-08-30 11:50:30)