> 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. > > 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. Wilco
