http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52607
--- Comment #21 from Marc Glisse <marc.glisse at normalesup dot org> 2012-03-27 18:21:39 UTC --- (In reply to comment #20) > I don't like much the calls to ix86_expand_vec_perm_const_1, if you are > looking > for exactly two insn permutations, Actually, it isn't just 2 insn. The call in expand_vec_perm_vperm2f128_merge can take 3, and the calls in expand_vec_perm_perm_blend(...,true) up to 4 (this is how I get a maximum of 9 insn, 1+2*4). But some more splits of ix86_expand_vec_perm_const_1 to avoid recursive calls should be doable, if you don't like the recursion. > then really the two insn permutation > functions should be groupped together into expand_vec_perm_2 and you should > call that instead, or if it is 1 or 2, then expand_vec_perm_1 || > expand_vec_perm_2. Yes, this grouping by size makes sense, whether it ends up being used or not. Although there are expanders in the "3" category that occasionally get lucky and generate only 2 :-) > expand_vec_perm_vperm2f128_merge has probably swapped the meaning of dfirst > and > dsecond permutations when it first performs the dsecond permutation. If you are just talking of the naming of the variables, yes, I completely agree they should be swapped (or given more explicit names, like swap_lanes and dintra).
