This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] [tree-ssa] Fix handling of BIT_FIELD_REFs and VECTOR_TYPEs


> > > Fortunately, this is easy to do: do all your operations and then
> > > construct the new value all at once with
> > > a_6 = CONSTRUCTOR (t_5, t_6, t_7, t_8).
> >
> > Hmm.  I may have lied here.  I do think that this is the right
> > representation, but we'll need to modify get_expr_operands in
> > order to make this work; at present constructors are only
> > present in gimple as vector constants.

No, it works because CONSTRUCTOR goes through the TREE_LIST for the items and,
from there, to the four (in this case) items.  Vector initializers already use
CONSTRUCTOR, like in

    int x __attribute__ ((vector_size (16))) = { a, 2*a, 3*a, 4*a };

My vector lowering patch now works fine with this approach, without using any
VDEFs/VUSEs for VECTOR_TYPEs.  In the end I am using BIT_FIELD_REF for the
source vectors, CONSTRUCTOR to build the result, and VIEW_CONVERT_EXPR to
optimize cases where it is possible to work a word at a time instead of a
vector element at a time.  The code is longer than what's in optabs.c, but it
optimizes more cases.

On tree-profiling branch I can run it always, just before the expander,
together with tree-complex and instead of those parts of the expander.  I
started the regtests before leaving the office.

> Does this mean I'm misusing the constructor

Based on the snippet you sent, it is not different from what I'm doing with
CONSTRUCTOR, so you should be doing right.

Paolo




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]