https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99785
--- Comment #17 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Jeff Muizelaar from comment #14) > re: __builtin_shuffle vs __builtin_shufflevector - It looks like > __builtin_shuffle doesn't support constructing vectors of a different size > than input type. That's mostly what we're using __builtin_shufflevector for. > __builtin_shufflevector > https://github.com/servo/webrender/blob/master/swgl/src/vector_type.h Indeed that's more powerful that __builtin_shuffle. It would map loosely as to what (vec_select (vec_concat ....) ...) on RTL can do but on GIMPLE we don't have a 1:1 match though I've thought of extending it this way at multiple occasions (by extending the existing VEC_PERM_EXPR, basically relaxing the set of valid operands/results). The complication of doing that is always that targets need to be made aware of the possibilities. At least internally I've also pondered allowing a scalar as input serving as single-element vector. > I briefly tried to get the gcc variant of the code compiling with clang but > ran into a number of issues including clang's lack of support for > '__builtin_shuffle'. If you'd like to try, the swgl code is pretty easy to > build locally if you. You should be able to just checkout > https://github.com/servo/webrender/ navigate to the the 'swgl' directory and > run 'cargo build --release' > > re: inlining huge functions - We tried not inlining blend_pixels with clang > and it seems to have a negative impact on a number of benchmarks. Did you report this as an issue to them? That is, leaving auto-inlining to clangs heuristic and those not working?
