On Wed, Sep 16, 2020 at 10:31:54AM +0200, Richard Biener wrote:
> On Tue, Sep 15, 2020 at 6:18 PM Segher Boessenkool
> wrote:
> >
> > On Tue, Sep 15, 2020 at 08:51:09AM +0200, Richard Biener wrote:
> > > On Tue, Sep 15, 2020 at 5:56 AM luoxhu wrote:
> > > > > u[n % 4] = i;
> > > > >
> > > > >
On Wed, Sep 16, 2020 at 8:15 AM luoxhu wrote:
>
>
>
> On 2020/9/15 14:51, Richard Biener wrote:
>
>
> >> I only see VAR_DECL and PARM_DECL, is there any function to check the tree
> >> variable is global? I added DECL_REGISTER, but the RTL still expands to
> >> stack:
> >
> > is_global_var () or
On Tue, Sep 15, 2020 at 6:18 PM Segher Boessenkool
wrote:
>
> On Tue, Sep 15, 2020 at 08:51:09AM +0200, Richard Biener wrote:
> > On Tue, Sep 15, 2020 at 5:56 AM luoxhu wrote:
> > > > u[n % 4] = i;
> > > >
> > > > I guess. Is the % 4 mandated by the vec_insert semantics btw?
>
> (As an aside
On 2020/9/15 14:51, Richard Biener wrote:
>> I only see VAR_DECL and PARM_DECL, is there any function to check the tree
>> variable is global? I added DECL_REGISTER, but the RTL still expands to
>> stack:
>
> is_global_var () or alternatively !auto_var_in_fn_p (), I think doing
> IFN_SET onl
On Tue, Sep 15, 2020 at 08:51:09AM +0200, Richard Biener wrote:
> On Tue, Sep 15, 2020 at 5:56 AM luoxhu wrote:
> > > u[n % 4] = i;
> > >
> > > I guess. Is the % 4 mandated by the vec_insert semantics btw?
(As an aside -- please use "& 3" instead: that works fine if n is signed
as well, but
On Tue, Sep 15, 2020 at 5:56 AM luoxhu wrote:
>
>
>
> On 2020/9/14 17:47, Richard Biener wrote:
> > On Mon, Sep 14, 2020 at 10:05 AM luoxhu wrote:
>
> >> Not sure whether this reflects the issues you discussed above.
> >> I constructed below test cases and tested with and without this patch,
> >>
On 2020/9/14 17:47, Richard Biener wrote:
On Mon, Sep 14, 2020 at 10:05 AM luoxhu wrote:
Not sure whether this reflects the issues you discussed above.
I constructed below test cases and tested with and without this patch,
only if "a+c"(which means store only), the performance is getting ba
On Mon, Sep 14, 2020 at 11:47:52AM +0100, Richard Sandiford wrote:
> Would it be worth changing the optab so that the input and output are
> separate? Having a single operand would be justified if the operation
> was only supposed to touch the selected bytes, but most targets wouldn't
> guarantee
On Mon, Sep 14, 2020 at 11:47:56AM +0200, Richard Biener wrote:
> this should be
>
>u[n % 4] = i;
>
> I guess. Is the % 4 mandated by the vec_insert semantics btw?
Yes:
VEC_INSERT (ARG1, ARG2, ARG3)
Purpose: Returns a copy of vector ARG2 with element ARG3 replaced by
the value of ARG
On Thu, Sep 10, 2020 at 12:08:44PM +0200, Richard Biener wrote:
> On Wed, Sep 9, 2020 at 6:03 PM Segher Boessenkool
> wrote:
> > There often are problems over function calls (where the compiler cannot
> > usually *see* how something is used).
>
> Yep. The best way would be to use small loads and
Richard Biener writes:
> On Mon, Sep 14, 2020 at 12:47 PM Richard Sandiford
> wrote:
>>
>> Richard Biener via Gcc-patches writes:
>> > On gimple the above function (after fixing it) looks like
>> >
>> > VIEW_CONVERT_EXPR(u)[_1] = i_4(D);
>> >
>> > and the IFN idea I had would - for non-global
On Mon, Sep 14, 2020 at 12:47 PM Richard Sandiford
wrote:
>
> Richard Biener via Gcc-patches writes:
> > On gimple the above function (after fixing it) looks like
> >
> > VIEW_CONVERT_EXPR(u)[_1] = i_4(D);
> >
> > and the IFN idea I had would - for non-global memory 'u' only - transform
> > thi
Richard Biener via Gcc-patches writes:
> On gimple the above function (after fixing it) looks like
>
> VIEW_CONVERT_EXPR(u)[_1] = i_4(D);
>
> and the IFN idea I had would - for non-global memory 'u' only - transform
> this to
>
> vector_register_2 = u;
> vector_register_3 = .IFN_VEC_SET (vec
On Mon, Sep 14, 2020 at 10:05 AM luoxhu wrote:
>
>
>
> On 2020/9/10 18:08, Richard Biener wrote:
> > On Wed, Sep 9, 2020 at 6:03 PM Segher Boessenkool
> > wrote:
> >>
> >> On Wed, Sep 09, 2020 at 04:28:19PM +0200, Richard Biener wrote:
> >>> On Wed, Sep 9, 2020 at 3:49 PM Segher Boessenkool
> >>>
On 2020/9/10 18:08, Richard Biener wrote:
> On Wed, Sep 9, 2020 at 6:03 PM Segher Boessenkool
> wrote:
>>
>> On Wed, Sep 09, 2020 at 04:28:19PM +0200, Richard Biener wrote:
>>> On Wed, Sep 9, 2020 at 3:49 PM Segher Boessenkool
>>> wrote:
Hi!
On Tue, Sep 08, 2020 at 10:26:51
On Wed, Sep 9, 2020 at 6:03 PM Segher Boessenkool
wrote:
>
> On Wed, Sep 09, 2020 at 04:28:19PM +0200, Richard Biener wrote:
> > On Wed, Sep 9, 2020 at 3:49 PM Segher Boessenkool
> > wrote:
> > >
> > > Hi!
> > >
> > > On Tue, Sep 08, 2020 at 10:26:51AM +0200, Richard Biener wrote:
> > > > Hmm, ye
On Wed, Sep 09, 2020 at 04:28:19PM +0200, Richard Biener wrote:
> On Wed, Sep 9, 2020 at 3:49 PM Segher Boessenkool
> wrote:
> >
> > Hi!
> >
> > On Tue, Sep 08, 2020 at 10:26:51AM +0200, Richard Biener wrote:
> > > Hmm, yeah - I guess that's what should be addressed first then.
> > > I'm quite sur
On Wed, Sep 9, 2020 at 3:49 PM Segher Boessenkool
wrote:
>
> Hi!
>
> On Tue, Sep 08, 2020 at 10:26:51AM +0200, Richard Biener wrote:
> > Hmm, yeah - I guess that's what should be addressed first then.
> > I'm quite sure that in case 'v' is not on the stack but in memory like
> > in my case a SImod
Hi!
On Tue, Sep 08, 2020 at 10:26:51AM +0200, Richard Biener wrote:
> Hmm, yeah - I guess that's what should be addressed first then.
> I'm quite sure that in case 'v' is not on the stack but in memory like
> in my case a SImode store is better than what we get from
> vec_insert - in fact vec_inse
On Wed, Sep 9, 2020 at 3:47 AM luoxhu wrote:
>
>
>
> On 2020/9/8 16:26, Richard Biener wrote:
> >> Seems not only pseudo, for example "v = vec_insert (i, v, n);"
> >> the vector variable will be store to stack first, then [r112:DI] is a
> >> memory here to be processed. So the patch loads it from
On 2020/9/8 16:26, Richard Biener wrote:
>> Seems not only pseudo, for example "v = vec_insert (i, v, n);"
>> the vector variable will be store to stack first, then [r112:DI] is a
>> memory here to be processed. So the patch loads it from stack(insn #10) to
>> temp vector register first, and st
On Tue, Sep 8, 2020 at 10:11 AM luoxhu wrote:
>
> Hi Richi,
>
> On 2020/9/7 19:57, Richard Biener wrote:
> > + if (TREE_CODE (to) == ARRAY_REF)
> > + {
> > + tree op0 = TREE_OPERAND (to, 0);
> > + if (TREE_CODE (op0) == VIEW_CONVERT_EXPR
> > + && expand_view_
Hi Richi,
On 2020/9/7 19:57, Richard Biener wrote:
> + if (TREE_CODE (to) == ARRAY_REF)
> + {
> + tree op0 = TREE_OPERAND (to, 0);
> + if (TREE_CODE (op0) == VIEW_CONVERT_EXPR
> + && expand_view_convert_to_vec_set (to, from, to_rtx))
> + {
> +
On Mon, Sep 7, 2020 at 7:44 AM luoxhu wrote:
>
> Hi,
>
> On 2020/9/4 18:23, Segher Boessenkool wrote:
> >> diff --git a/gcc/config/rs6000/rs6000-c.c b/gcc/config/rs6000/rs6000-c.c
> >> index 03b00738a5e..00c65311f76 100644
> >> --- a/gcc/config/rs6000/rs6000-c.c
> >> +++ b/gcc/config/rs6000/rs6000
00:00:00 2001
From: Xiong Hu Luo
Date: Wed, 19 Aug 2020 03:54:17 -0500
Subject: [PATCH v2] rs6000: Expand vec_insert in expander instead of gimple
[PR79251]
vec_insert accepts 3 arguments, arg0 is input vector, arg1 is the value
to be insert, arg2 is the place to insert arg1 to arg0. Current
25 matches
Mail list logo
