gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Michael Matz
> Sent: 24 October 2016 10:02
> To: Bin.Cheng
> Cc: Jeff Law; gcc-patches List
> Subject: Re: Gimple loop splitting v2
>
> Hi,
>
> On Mon, 24 Oct 2016, Bin.Cheng wrote:
>
> > Unfortunately I didn't r
Hi,
On Mon, 24 Oct 2016, Bin.Cheng wrote:
> Unfortunately I didn't reproduce the improvement in my run on AArch64, I
> will double check if I made some mistakes.
Yeah, our regular testers also didn't pick up these kinds of improvements.
As I said, the machine was quite jumpy (though not loade
On Thu, Oct 20, 2016 at 3:55 PM, Bin.Cheng wrote:
> On Thu, Oct 20, 2016 at 3:43 PM, Michael Matz wrote:
>> Hi,
>>
>> On Sat, 5 Dec 2015, Jeff Law wrote:
>>
>>> Nit. I don't think you want a comma after "so". And it looks like your
>>> comment got truncated as well.
>>>
>>> With the comment abo
On 10/20/2016 08:43 AM, Michael Matz wrote:
Hi,
On Sat, 5 Dec 2015, Jeff Law wrote:
Nit. I don't think you want a comma after "so". And it looks like your
comment got truncated as well.
With the comment above fixed, this is fine for the trunk.
I'm terribly sorry to have dropped the ball h
On Thu, Oct 20, 2016 at 3:43 PM, Michael Matz wrote:
> Hi,
>
> On Sat, 5 Dec 2015, Jeff Law wrote:
>
>> Nit. I don't think you want a comma after "so". And it looks like your
>> comment got truncated as well.
>>
>> With the comment above fixed, this is fine for the trunk.
>
> I'm terribly sorry
Hi,
On Sat, 5 Dec 2015, Jeff Law wrote:
> Nit. I don't think you want a comma after "so". And it looks like your
> comment got truncated as well.
>
> With the comment above fixed, this is fine for the trunk.
I'm terribly sorry to have dropped the ball here, but I've committed this
now after
On Wed, Jul 27, 2016 at 8:17 AM, Andrew Pinski wrote:
> On Tue, Jul 26, 2016 at 4:32 AM, Richard Biener
> wrote:
>> On Mon, Jul 25, 2016 at 10:57 PM, Andrew Pinski wrote:
>>> On Wed, Dec 2, 2015 at 5:23 AM, Michael Matz wrote:
Hi,
On Tue, 1 Dec 2015, Jeff Law wrote:
> >
On Tue, Jul 26, 2016 at 4:32 AM, Richard Biener
wrote:
> On Mon, Jul 25, 2016 at 10:57 PM, Andrew Pinski wrote:
>> On Wed, Dec 2, 2015 at 5:23 AM, Michael Matz wrote:
>>> Hi,
>>>
>>> On Tue, 1 Dec 2015, Jeff Law wrote:
>>>
> So, okay for trunk?
-ENOPATCH
>>>
>>> Sigh :)
>>> Here it is.
On Mon, Jul 25, 2016 at 10:57 PM, Andrew Pinski wrote:
> On Wed, Dec 2, 2015 at 5:23 AM, Michael Matz wrote:
>> Hi,
>>
>> On Tue, 1 Dec 2015, Jeff Law wrote:
>>
>>> > So, okay for trunk?
>>> -ENOPATCH
>>
>> Sigh :)
>> Here it is.
>
>
> I found one problem with it.
> Take:
> void f(int *a, int M,
On Wed, Dec 2, 2015 at 5:23 AM, Michael Matz wrote:
> Hi,
>
> On Tue, 1 Dec 2015, Jeff Law wrote:
>
>> > So, okay for trunk?
>> -ENOPATCH
>
> Sigh :)
> Here it is.
I found one problem with it.
Take:
void f(int *a, int M, int *b)
{
for(int i = 0; i <= M; i++)
{
if (i < M)
a[i
Hi,
On Sun, 24 Jul 2016, Andrew Pinski wrote:
> What ever happened to this patch?
It got accepted but I deferred inclusion in GCC 6 because it
was late in the cycle then and performance results didn't show super
improvements (only looked at cpu2006). No regressions, but no nice
speedups eith
On Thu, Nov 12, 2015 at 8:52 AM, Michael Matz wrote:
> Hello,
>
> this new pass implements loop iteration space splitting for loops that
> contain a conditional that's always true for one part of the iteration
> space and false for the other, i.e. such situations:
>
> for (i = beg; i < end; i++)
On 12/02/2015 06:23 AM, Michael Matz wrote:
Hi,
On Tue, 1 Dec 2015, Jeff Law wrote:
So, okay for trunk?
-ENOPATCH
Sigh :)
Here it is.
Ciao,
Michael.
* common.opt (-fsplit-loops): New flag.
* passes.def (pass_loop_split): Add.
* opts.c (default_options_table): Add O
Hi,
On Tue, 1 Dec 2015, Jeff Law wrote:
> > So, okay for trunk?
> -ENOPATCH
Sigh :)
Here it is.
Ciao,
Michael.
* common.opt (-fsplit-loops): New flag.
* passes.def (pass_loop_split): Add.
* opts.c (default_options_table): Add OPT_fsplit_loops entry at -O3.
(enab
On 12/01/2015 09:46 AM, Michael Matz wrote:
Hi,
So, okay for trunk?
-ENOPATCH
Jeff
Hi,
On Mon, 16 Nov 2015, Jeff Law wrote:
> OK, if you want to keep them, then have a consistent way to turn them
> on/off for future debugging. if0/if1 doesn't provide much of a clue to
> someone else what to turn on/off if they need to debug this stuff.
> > > I don't see any negative tests -
On 11/16/2015 09:05 AM, Michael Matz wrote:
It's a prerequisite indeed, but not enough in itself.
Sigh. OK. One can always hope.
hmmer is actually quite interesting because it's a fairly isolated hot
loop posing quite challenging problems for us :)
Sounds like it. Essentially, it's a TO
Hi,
On Thu, 12 Nov 2015, Jeff Law wrote:
> > this new pass implements loop iteration space splitting for loops that
> > contain a conditional that's always true for one part of the iteration
> > space and false for the other, i.e. such situations:
> FWIW, Ajit suggested the same transformation ea
On 11/12/2015 09:52 AM, Michael Matz wrote:
Hello,
this new pass implements loop iteration space splitting for loops that
contain a conditional that's always true for one part of the iteration
space and false for the other, i.e. such situations:
FWIW, Ajit suggested the same transformation earli
Hello,
this new pass implements loop iteration space splitting for loops that
contain a conditional that's always true for one part of the iteration
space and false for the other, i.e. such situations:
for (i = beg; i < end; i++)
if (i < p)
dothis();
else
dothat();
this i
20 matches
Mail list logo
