On 10/18/13 05:05, James Greenhalgh wrote:
On Fri, Oct 18, 2013 at 11:55:08AM +0100, Richard Biener wrote:
I suppose with Jeffs recent work on jump-threading through paths
this case in handled and the patch in this thread is obsolete or can
be reworked?
Yes, this patch is now obsolete, Jeff's
On 10/18/13 04:55, Richard Biener wrote:
On Fri, Jun 21, 2013 at 11:21 PM, Steve Ellcey wrote:
On Fri, 2013-06-21 at 17:43 +0100, James Greenhalgh wrote:
So to my mind, this is all far too tied up in pass ordering details to
resolve. Given that all the threading opportunities for my patch are
On Fri, Oct 18, 2013 at 11:55:08AM +0100, Richard Biener wrote:
> I suppose with Jeffs recent work on jump-threading through paths
> this case in handled and the patch in this thread is obsolete or can
> be reworked?
Yes, this patch is now obsolete, Jeff's solution is much more
elegant :-)
Thanks
On Fri, Jun 21, 2013 at 11:21 PM, Steve Ellcey wrote:
> On Fri, 2013-06-21 at 17:43 +0100, James Greenhalgh wrote:
>
>> So to my mind, this is all far too tied up in pass ordering details to
>> resolve. Given that all the threading opportunities for my patch are found
>> in dom1 and how fragile th
On Fri, 2013-06-21 at 17:43 +0100, James Greenhalgh wrote:
> So to my mind, this is all far too tied up in pass ordering details to
> resolve. Given that all the threading opportunities for my patch are found
> in dom1 and how fragile the positioning of dom1 is, there is not a great
> deal I can d
> While testing it I noticed that the final executable
> is larger with your patch then with mine. Here are the sizes of the
> bare-metal executables I created using the same flags I sent you
> earlier, the first has no switch optimization, the second one uses my
> plugin optimization, and the th
On Wed, 2013-06-19 at 14:19 +0100, James Greenhalgh wrote:
> Please let me know if this fixes the performance issues you
> were seeing and if you have any other comments.
>
> FWIW I've bootstrapped and regression tested this version of
> the patch on x86_64 and ARM with no regressions.
>
> Thank
> -Original Message-
> From: Steve Ellcey [mailto:sell...@mips.com]
> Sent: 14 June 2013 19:07
>
> With my version the compiler calls gimple_duplicate_sese_region from
> duplicate_blocks 60 times. With your patch it calls
> gimple_duplicate_sese_region from duplicate_thread_path 16 times.
On Fri, 2013-06-14 at 00:08 +0100, James Greenhalgh wrote:
> I see only minor cosmetic differences (Placement of labels,
> numbering of labels) between the two generated assembly files.
>
> Perhaps you could share the flags you were using and I can try to
> figure out which paths I seem to be mis
On Thu, Jun 13, 2013 at 08:29:08PM +0100, Steve Ellcey wrote:
> On Fri, 2013-06-07 at 16:14 +0100, James Greenhalgh wrote:
>
> > Beyond that, the path search code is modified from Steve's patch
> > to only perform one depth first search, and the path copy code
> > is modified to purge the region e
On Fri, 2013-06-07 at 16:14 +0100, James Greenhalgh wrote:
> Beyond that, the path search code is modified from Steve's patch
> to only perform one depth first search, and the path copy code
> is modified to purge the region entry and exit edges for those
> which traditional jump-threading may co
11 matches
Mail list logo
