On Sat, Aug 18, 2012 at 11:59 AM, Marc Glisse wrote:
> Hello,
>
> here is a new patch (passes bootstrap+regtest), which only combines
> permutations if the result is the identity. I'll file a PR about more
> general
> combinations to link to this conversation and the cost hook proposition.
>
> Ok?
Hello,
here is a new patch (passes bootstrap+regtest), which only combines
permutations if the result is the identity. I'll file a PR about more general
combinations to link to this conversation and the cost hook proposition.
Ok?
2012-08-18 Marc Glisse
gcc/
* fold-const.c (fold_ter
On Wed, 15 Aug 2012, Richard Guenther wrote:
> On Wed, Aug 15, 2012 at 1:56 PM, Ramana Radhakrishnan
> wrote:
> > Of-course, the problem here is this change of semantics with the hook
> > TARGET_VEC_PERM_CONST_OK. Targets were expanding to generic permutes
> > with constants in the *absence* of be
On Wed, Aug 15, 2012 at 2:53 PM, Jakub Jelinek wrote:
> On Wed, Aug 15, 2012 at 02:36:54PM +0200, Richard Guenther wrote:
>> On Wed, Aug 15, 2012 at 2:29 PM, Jakub Jelinek wrote:
>> > On Wed, Aug 15, 2012 at 02:15:03PM +0200, Richard Guenther wrote:
>> >> Ok. That would still leave us with the i
On Wed, Aug 15, 2012 at 02:36:54PM +0200, Richard Guenther wrote:
> On Wed, Aug 15, 2012 at 2:29 PM, Jakub Jelinek wrote:
> > On Wed, Aug 15, 2012 at 02:15:03PM +0200, Richard Guenther wrote:
> >> Ok. That would still leave us with the issue Ramana brought up - the
> >> target hook returning true
On Wed, Aug 15, 2012 at 2:29 PM, Jakub Jelinek wrote:
> On Wed, Aug 15, 2012 at 02:15:03PM +0200, Richard Guenther wrote:
>> Ok. That would still leave us with the issue Ramana brought up - the
>> target hook returning true unconditionally if a generic permute is
>> implemented.
>> We just avoid
On Wed, Aug 15, 2012 at 02:15:03PM +0200, Richard Guenther wrote:
> Ok. That would still leave us with the issue Ramana brought up - the
> target hook returning true unconditionally if a generic permute is
> implemented.
> We just avoid generic expansion by tree-vect-generic.c that way.
Yeah, if
On 15 August 2012 13:07, Jakub Jelinek wrote:
> On Wed, Aug 15, 2012 at 01:46:05PM +0200, Richard Guenther wrote:
>> Well, we're waiting for someone to break the tie ... I'd go with the original
>> patch, improving the backends where necessary.
>
> E.g. i?86/x86_64 with just plain -msse2 has only
On Wed, Aug 15, 2012 at 2:07 PM, Jakub Jelinek wrote:
> On Wed, Aug 15, 2012 at 01:46:05PM +0200, Richard Guenther wrote:
>> Well, we're waiting for someone to break the tie ... I'd go with the original
>> patch, improving the backends where necessary.
>
> E.g. i?86/x86_64 with just plain -msse2 h
On Wed, Aug 15, 2012 at 01:46:05PM +0200, Richard Guenther wrote:
> Well, we're waiting for someone to break the tie ... I'd go with the original
> patch, improving the backends where necessary.
E.g. i?86/x86_64 with just plain -msse2 has only very small subset of
constant shuffles (and no variabl
On Wed, Aug 15, 2012 at 1:56 PM, Ramana Radhakrishnan
wrote:
> [It looks like I missed hitting the send button on this response]
>
>>
>> Seems to be one instruction shorter at least ;-) Yes, there can be much
>> worse regressions than that because of the patch (like 40 instructions
>> instead of 4
[It looks like I missed hitting the send button on this response]
>
> Seems to be one instruction shorter at least ;-) Yes, there can be much
> worse regressions than that because of the patch (like 40 instructions
> instead of 4, in the x86 backend).
If this is replacing 4 instructions with 40 i
On Wed, Aug 15, 2012 at 1:22 PM, Marc Glisse wrote:
> On Mon, 13 Aug 2012, Marc Glisse wrote:
>
>> I'll give it a few more days for the conversation to settle, so I know
>> what I should do between:
>> - the barely modified patch you accepted,
>> - the check asked by Jakub,
>> - the restriction to
On Mon, 13 Aug 2012, Marc Glisse wrote:
I'll give it a few more days for the conversation to settle, so I know what I
should do between:
- the barely modified patch you accepted,
- the check asked by Jakub,
- the restriction to identity that prevents any regression (well...),
- something else?
On Mon, 13 Aug 2012, Marc Glisse wrote:
On Mon, 13 Aug 2012, Richard Guenther wrote:
If your new predicate would match more places (can you do a quick search?)
You mean: if there are more optimizations that either already check for
double use in the same statement, or could benefit from doi
On Mon, Aug 13, 2012 at 4:12 PM, Ramana Radhakrishnan
wrote:
> On 13 August 2012 14:54, Jakub Jelinek wrote:
>> On Mon, Aug 13, 2012 at 03:45:00PM +0200, Marc Glisse wrote:
>>> On Mon, 13 Aug 2012, Jakub Jelinek wrote:
>>>
>>> >On Mon, Aug 13, 2012 at 03:13:26PM +0200, Richard Guenther wrote:
>>>
On Mon, 13 Aug 2012, Ramana Radhakrishnan wrote:
On 13 August 2012 14:21, Marc Glisse wrote:
On Mon, 13 Aug 2012, Richard Guenther wrote:
On Mon, Aug 13, 2012 at 3:12 PM, Ramana Radhakrishnan
wrote:
I guess people will complain soon enough if this causes horrible
performance
regressions
On 13 August 2012 14:54, Jakub Jelinek wrote:
> On Mon, Aug 13, 2012 at 03:45:00PM +0200, Marc Glisse wrote:
>> On Mon, 13 Aug 2012, Jakub Jelinek wrote:
>>
>> >On Mon, Aug 13, 2012 at 03:13:26PM +0200, Richard Guenther wrote:
>> >>The patch does not do that. It merely assumes that the target kno
On 13 August 2012 14:21, Marc Glisse wrote:
> On Mon, 13 Aug 2012, Richard Guenther wrote:
>
>> On Mon, Aug 13, 2012 at 3:12 PM, Ramana Radhakrishnan
>> wrote:
I guess people will complain soon enough if this causes horrible
performance
regressions in vectorized code.
>>>
On Mon, Aug 13, 2012 at 03:45:00PM +0200, Marc Glisse wrote:
> On Mon, 13 Aug 2012, Jakub Jelinek wrote:
>
> >On Mon, Aug 13, 2012 at 03:13:26PM +0200, Richard Guenther wrote:
> >>The patch does not do that. It merely assumes that the target knows
> >>how to perform an optimal constant permute an
On Mon, 13 Aug 2012, Jakub Jelinek wrote:
On Mon, Aug 13, 2012 at 03:13:26PM +0200, Richard Guenther wrote:
The patch does not do that. It merely assumes that the target knows
how to perform an optimal constant permute and that two constant
permutes never generate better code than a single one
On Mon, 13 Aug 2012, Richard Guenther wrote:
+ /* Check that it is only used here. We cannot use has_single_use
+ since the expression is using it twice itself... */
Ah ... so then
|| num_imm_uses (op0) != 2
Ah, ok, that's simpler indeed, but there were such dire warnings to
On Mon, Aug 13, 2012 at 03:13:26PM +0200, Richard Guenther wrote:
> On Mon, Aug 13, 2012 at 3:12 PM, Ramana Radhakrishnan
> wrote:
> >>
> >> I guess people will complain soon enough if this causes horrible
> >> performance
> >> regressions in vectorized code.
> >
> > Not having looked at your pat
On Mon, 13 Aug 2012, Richard Guenther wrote:
On Mon, Aug 13, 2012 at 3:12 PM, Ramana Radhakrishnan
wrote:
I guess people will complain soon enough if this causes horrible performance
regressions in vectorized code.
Not having looked at your patch in great detail,. surely what we don't
want
On Mon, Aug 13, 2012 at 3:12 PM, Ramana Radhakrishnan
wrote:
>>
>> I guess people will complain soon enough if this causes horrible performance
>> regressions in vectorized code.
>
> Not having looked at your patch in great detail,. surely what we don't
> want is a situation where 2 constant permu
>
> I guess people will complain soon enough if this causes horrible performance
> regressions in vectorized code.
Not having looked at your patch in great detail,. surely what we don't
want is a situation where 2 constant permutations are converted into
one generic permute. Based on a quick read
On Mon, Aug 13, 2012 at 3:03 PM, Marc Glisse wrote:
> On Mon, 13 Aug 2012, Richard Guenther wrote:
>
>> On Sat, Aug 11, 2012 at 2:25 PM, Marc Glisse wrote:
>>>
>>> On Fri, 10 Aug 2012, Marc Glisse wrote:
>>>
1) I am not sure we always want to combine permutations. Indeed, someone
(user?
On Mon, 13 Aug 2012, Richard Guenther wrote:
On Sat, Aug 11, 2012 at 2:25 PM, Marc Glisse wrote:
On Fri, 10 Aug 2012, Marc Glisse wrote:
1) I am not sure we always want to combine permutations. Indeed, someone
(user? vectorizer?) may have written 2 permutations to help the backend
generate o
On Sat, Aug 11, 2012 at 2:25 PM, Marc Glisse wrote:
> On Fri, 10 Aug 2012, Marc Glisse wrote:
>
>> this patch detects permutations of permutations and merges them. It also
>> canonicalizes permutations a bit more.
>>
>> There are several issues with this patch:
>>
>> 1) I am not sure we always wan
On Fri, 10 Aug 2012, Marc Glisse wrote:
this patch detects permutations of permutations and merges them. It also
canonicalizes permutations a bit more.
There are several issues with this patch:
1) I am not sure we always want to combine permutations. Indeed, someone
(user? vectorizer?) may h
On Fri, 10 Aug 2012, Marc Glisse wrote:
There are several issues with this patch:
Oups:
5) and the testcase needs fixing, just like Jakub just fixed Richard's
testcase, to avoid ABI warnings. But that's easy.
--
Marc Glisse
31 matches
Mail list logo
