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: Vector subscription patch


On Thu, Oct 21, 2010 at 12:06 AM, Richard Henderson <rth@redhat.com> wrote:
> On 10/20/2010 02:47 PM, Richard Guenther wrote:
>> On Wed, Oct 20, 2010 at 11:36 PM, Richard Henderson <rth@redhat.com> wrote:
>>> On 10/20/2010 02:27 PM, Richard Guenther wrote:
>>>> A VIEW_CONVERT_EXPR <ARRAY_TYPE, register>[index] should also work.
>>>
>>> That should mark the variable addressable iff index is non-constant?
>>
>> No, the variable will still be in SSA form, thus the expanders have to take
>> extra care. ?The variable will be non-addressable but in non-SSA form
>> if there are partial stores though.
>
> Er, of course there will be partial stores. ?That's the
> whole point of setting an element.
>
> It's almost certainly better, then, to have a new code
>
> ?vector<T> v;
> ?T t;
>
> ?v1 = VEC_SET_EXPR(v0, index, t0);
> ?t1 = VEC_EXT_EXPR(v0, index)
>
> which can at least keep V in SSA form, and avoid playing
> silly games with ARRAY_REF_EXPR.

;)

We also lack a genuine vector construction tree and use CONSTRUCTOR
for it.  But your VEC_SET_EXPR sounds much like the BIT_FIELD_EXPR
I want to invent for the modify part of a read-modify-write bitfield store.

Anyway, the question is what we want to do now, given we're close to
stage3 and nothing in the middle-end currently knows about a
VEC_SET_EXPR or a VEC_EXT_EXPR.

Doing the addressable memory thing will pessimize -O0 for sure, but
the optimizers should be able to fix it up.  We can easily special-case
constant indices on the RHS with BIT_FIELD_REF.

Richard.

>
> r~
>


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