Hi! On Sun, Mar 11, 2018 at 10:23:02AM -0500, Peter Bergner wrote: > PR83789 shows a problem in the builtin expansion code not calling the correct > define_insn, given the correct mode (32-bit versus 64-bit). One could add > tests in this code to call the correct pattern, but it's easier to create > a common define_expand which everyone can call that does the right thing. > This allows us to clean up all the callers, making for much simpler code. > This also fixes the issue that Segher mentioned that this needs fixing for > multiple other vector modes and not just the one mentioned in the bugzilla.
> P.S. I will be away on vacation for the neek week, so if this is ok, I won't > be able to commit the patch until I return. Unless you want to commit > it Segher and watch for fallout. It's up to you. There is no hurry I think? And some changes are needed, so I'll leave it to you. > +; The following patterns embody what lvx should usually look like. > +(define_expand "altivec_lvx_<VM2:mode>" > + [(set (match_operand:VM2 0 "register_operand" "") > + (match_operand:VM2 1 "altivec_indexed_or_indirect_operand" ""))] No "" please. Expanders do not have constraints. > #ifdef HAVE_V8HFmode > - else if (mode == V8HFmode) > - stvx = TARGET_64BIT > - ? gen_altivec_stvx_v8hf_1op (src_exp, memory_address) > - : gen_altivec_stvx_v8hf_1op_si (src_exp, memory_address); > + else if (mode == V8HFmode) > + stvx = gen_altivec_stvx_v8hf (src_exp, dest_exp); > #endif Btw, don't we always have V8HFmode these days? The patch is fine with those trivialities fixed. Okay for trunk. Thanks! Enjoy your vacation! Segher
