https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77399
--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Alexander Monakov from comment #6)
> Thanks. Any comment on having gimple lowering emit cleaner code in the first
> place?
well, I'm not sure if it is worth the trouble. FEs emit
return <<< Unknown tree: compound_literal_expr
v4sf D.1795 = {(float) VIEW_CONVERT_EXPR<int[4]>(f)[0], (float)
VIEW_CONVERT_EXPR<int[4]>(f)[1], (float) VIEW_CONVERT_EXPR<int[4]>(f)[2],
(float) VIEW_CONVERT_EXPR<int[4]>(f)[3]}; >>>;
and gimplification then forces the scalar computations to temporaries:
_1 = BIT_FIELD_REF <f, 32, 0>;
_2 = (float) _1;
_3 = BIT_FIELD_REF <f, 32, 32>;
_4 = (float) _3;
_5 = BIT_FIELD_REF <f, 32, 64>;
_6 = (float) _5;
_7 = BIT_FIELD_REF <f, 32, 96>;
_8 = (float) _7;
D.1797 = {_2, _4, _6, _8};
this is theoretically a point where stmt folding could replace it by
D.1797 = (float) f;
the code in forwprop would need to be moved to gimple-fold.c and eventually
the gimplifier needs to be changed to fold more stmts (it really should
fold all of them, with SSA edge following enabled -- the point we now
have SSA names as early as gimplification).
I think the real issue for writing vector code is that our GCC generic
vector extension has no casting support (or pack-/unpack-support). The
extension is closely modeled after openCL and IIRC openCL uses
"intrinsics" for these kind of operations?
So I still believe that the forwprop code should be extended, and eventually
the forwprop code should be moved to gimple-fold.c (invoked via fold_stmt),
aka "manually written" match.pd patterns.
