Re: [PATCH][ARM] one_cmpldi2 in NEON

[Andrew Stubbs <andrew_stubbs at mentor dot com>]

On 06/12/11 23:07, Richard Henderson wrote:
> On 12/06/2011 01:42 PM, Andrew Stubbs wrote:
> > On Tue 06 Dec 2011 21:05:30 GMT, Richard Henderson wrote:
> > > On 12/06/2011 09:59 AM, Andrew Stubbs wrote:
> > > > +(define_insn "*one_cmpldi2_neon"
> > > > +  [(set (match_operand:DI 0 "s_register_operand"     "=w,?&r,?&r,?w")
> > > > +    (not:DI (match_operand:DI 1 "s_register_operand" " w,  0,  r, w")))]
> > >
> > > alternative 0 == alternative 3?
> >
> > Yes and no. This is an idiom used in several places in neon.md. They
> > are the same, but only one or other is enabled at the same time (see
> > the "arch" attribute) so while both 'w' and 'r' options are always
> > available, the order of preference is different.
>
> Except that without *, I don't think this is what is actually achieved.
> Perhaps I'm mistaken about how register preferencing is handled in the
> current state of the register allocator...

Well .... I can demonstrate that it does work in a simple testcase, and 
it has a visible affect in benchmark figures.

Of course, that doesn't mean it doing it the right way. As far as I 
understand it the current implementation relies on the left-to-right 
priority of the constraints.

On A9, and other A-series parts, we want it to prefer 'w'-constraint 
registers, but still use 'r'-constraint registers if those are more 
convenient.

On A8, we want it to prefer 'r' registers, all else being equal, but 
still have the freedom to use 'w' registers if the values are already there.

From reading the internals manual, it's not clear to me what the '*' 
constraint modifier really means, or how it would work in this case? 
Could you enlighten me?

Andrew