This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
RE: PATCH: Add XOP 128-bit and 256-bit support for upcoming AMD Orochi processor.
- From: "rajagopal, dwarak" <dwarak dot rajagopal at amd dot com>
- To: "'Jan Hubicka'" <hubicka at ucw dot cz>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Cc: "Harle, Christophe" <christophe dot harle at amd dot com>, "Jagasia, Harsha" <harsha dot jagasia at amd dot com>, "'Jan Hubicka'" <hubicka at ucw dot cz>
- Date: Mon, 12 Oct 2009 09:38:41 -0700
- Subject: RE: PATCH: Add XOP 128-bit and 256-bit support for upcoming AMD Orochi processor.
Hi Honza,
I will be going to take over this patch from Harsha and wrap this up, so that I can check in this patch.
It would be great if you could answer the comments below from Harsha so that I will get more clarity.
Thanks,
Dwarak
Hi Honza,
I have gone through your feedback on the XOP patch and it makes sense and I will fix as per your suggestions.
However I am not entirely sure I understand the 2 comments below. Since Mike Meissner added these patterns, I mostly inherited them from him.
Can you please elaborate or provide some more guidance on what I need to do.
(Please see my comments below)
> +;; We don't have a straight 32-bit parallel multiply on XOP, so fake it with a
> +;; multiply/add. In general, we expect the define_split to occur before
> +;; register allocation, so we have to handle the corner case where the target
> +;; is the same as one of the inputs.
> +(define_insn_and_split "*xop_mulv4si3"
> + [(set (match_operand:V4SI 0 "register_operand" "=&x")
> + (mult:V4SI (match_operand:V4SI 1 "register_operand" "%x")
> + (match_operand:V4SI 2 "nonimmediate_operand" "xm")))]
> > + "TARGET_XOP"
> > + "#"
> > + "&& (reload_completed
> > + || (!reg_mentioned_p (operands[0], operands[1])
> > + && !reg_mentioned_p (operands[0], operands[2])))"
>
> WHat happens when regs are mentioned?
> There are other cases 2 memory operand multiply-add splitting testing
> these, are we somehow making sure this conditional will always hold and
> we won't ICE not being able to satisfy the conditions?
Actually I am not even sure this xop_mulv4si3 pattern is needed because XOP now implies SSE 4.2 and AVX and so we can just generate the mulv4si3 patterns for AVX or SSE 4.1 when -mxop is used. Can I just remove this xop_mulv4si3 pattern then?
As for your reference to "other cases 2 memory operand multiply-add splitting", I assume you are referring to the vpmac/d* define_splits.
In XOP vpmac/d* instructions, there is no restriction any more for the destination reg to be same as the third src operand unlike SSE5. And only the second source can be memory. Also I don't see anything in the manual that the destination reg is enforced to be different from source 1, source 2 or source 3 operands individually either.
Should I then remove below from the pmac/d* patterns?
(!reg_mentioned_p (operands[0], operands[1])
> > + && !reg_mentioned_p (operands[0], operands[2]))
>
> > +;; The following are for the various unpack insns which doesn't need
> the first
> > +;; source operand, so we can just use the output operand for the first
> operand.
> > +;; This allows either of the other two operands to be a memory operand.
> We
> > +;; can't just use the first operand as an argument to the normal pperm
> because
> > +;; then an output only argument, suddenly becomes an input operand.
> > +(define_insn "xop_pperm_zero_v16qi_v8hi"
> > + [(set (match_operand:V8HI 0 "register_operand" "=x,x")
> > + (zero_extend:V8HI
> > + (vec_select:V8QI
> > + (match_operand:V16QI 1 "nonimmediate_operand" "xm,x")
> > + (match_operand 2 "" "")))) ;; parallel with const_int's
> > + (use (match_operand:V16QI 3 "nonimmediate_operand" "x,xm"))]
>
> Hmm, there is no unspec or omething that would make it clear that we can
> not ever somehow simplify into this form with operand 2 being something
> different than parallel with const_ints. I think this needs new
> predicate.
I can define a new predicate for it in predicates.md, but I am not sure how exactly to represent the "parallel with const ints" part.
Any suggestions?
Thanks,
Harsha