> 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). > >> 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. > 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. 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.] Thanks, -- Maxim Kuvyrkov www.linaro.org
