On Mar 4, 2015, at 6:00 PM, Wilco Dijkstra <wdijk...@arm.com> wrote: > >> Maxim Kuvyrkov wrote: >>> On Mar 4, 2015, at 3:30 PM, Wilco Dijkstra <wdijk...@arm.com> wrote: >>> >>>> Maxim Kuvyrkov wrote: >>>> >>>> You are removing the 2nd alternative that generates "abs" with your patch. >>>> While I agree >> that >>>> using "csneg" is faster on all implementations, can you say the same for >>>> "abs"? Especially >>>> given the fact that csneg requires 4 operands instead of abs'es 2? >>> >>> Yes, given that latencies of scalar SIMD instructions are typically worse >>> than integer >>> latencies. The number of operands is not an issue. >> >> One could make an argument that having an opportunity to use FP registers in >> high-reg-pressure >> code is valuable. But ... I can take your word for it. All-in-all, I don't >> have objections >> to your patch (note, this is a review, not approval, since I'm not an ARM >> maintainer). > > The idea of spilling between integer and FP register files sounds great but > GCC doesn't > support it unfortunately... > >>>> Wouldn't it be better to have (define_expand "abs<mode>2") that would >>>> expand into either >>>> csneg3<mode> or second alternative of current absdi2? >>> >>> How would that be possible? You'd have to delay expansion until after >>> register allocation, >>> which loses optimization opportunities. >> >> If abs<mode>2 define_expand is given arguments in DI mode that are FP >> register -- emit >> absdi2_insn. Otherwise (which will be 95% of the time) do what your patch >> does. > > I don't understand how that could ever happen - the new expansion happens > before register > allocation, so you'd never see FP registers as arguments.
A new instruction can be generated after reload by a folding optimizations or combine or other late optimizations. It's rare, but happens. > >>> And I still don't see how it would ever make sense >>> to execute integer operations as scalar SIMD. >>> >> >> Many GCC ports exploit ability to use FP registers for storage of integer >> values for the >> benefit of high-reg-pressure code. Ability to do some basic operations >> (like abs) on such >> integer values is beneficial for the same reason. > > I haven't seen any benefit - my previous patches severely discourage this > kind of bad > allocation and gave major performance gains. Despite that it still happens > way too often. > >> However, almost always FP-alternatives are not the only ones in the >> instruction pattern, and >> they are discouraged with "!". If you can't use "!" to discourage them >> (which you can't in a >> single-alternative case, like we got here) then your approach makes sense. >> [Yes, I know, you >> could fit that FP alternative into csneg pattern, but, probably, you would >> not want to spend >> your time on it, and I don't think it's important enough to ask you to.] > > Did you mean '?' ? It appears '?' discourages incorrect allocations while '*' > seems to make > things worse. Besides that, there are various issues with the cost > calculation in ira-costs.c > that result in incorrect register preferences. Yes, I meant "*" and "?". Thanks, -- Maxim Kuvyrkov www.linaro.org
