On Mon, Jun 11, 2012 at 7:16 PM, William J. Schmidt
wrote:
> On Mon, 2012-06-11 at 12:11 -0500, William J. Schmidt wrote:
>
>> I found this parameter that seems to correspond to well-predicted
>> conditional jumps:
>>
>> /* When branch is predicted to be taken with probability lower than this
>>
On Mon, 2012-06-11 at 12:11 -0500, William J. Schmidt wrote:
> I found this parameter that seems to correspond to well-predicted
> conditional jumps:
>
> /* When branch is predicted to be taken with probability lower than this
>threshold (in percent), then it is considered well predictable. *
On Mon, 2012-06-11 at 14:59 +0200, Richard Guenther wrote:
> On Mon, 11 Jun 2012, William J. Schmidt wrote:
>
> > On Mon, 2012-06-11 at 13:28 +0200, Richard Guenther wrote:
> > > On Mon, Jun 4, 2012 at 3:45 PM, William J. Schmidt
> > > wrote:
> > > > Hi Richard,
> > > >
> > > > Here's a revision
On Mon, 11 Jun 2012, William J. Schmidt wrote:
> On Mon, 2012-06-11 at 13:28 +0200, Richard Guenther wrote:
> > On Mon, Jun 4, 2012 at 3:45 PM, William J. Schmidt
> > wrote:
> > > Hi Richard,
> > >
> > > Here's a revision of the hoist-adjacent-loads patch. I'm sorry for the
> > > delay since the
On Mon, 2012-06-11 at 13:28 +0200, Richard Guenther wrote:
> On Mon, Jun 4, 2012 at 3:45 PM, William J. Schmidt
> wrote:
> > Hi Richard,
> >
> > Here's a revision of the hoist-adjacent-loads patch. I'm sorry for the
> > delay since the last revision, but my performance testing has been
> > blocke
On Mon, Jun 4, 2012 at 3:45 PM, William J. Schmidt
wrote:
> Hi Richard,
>
> Here's a revision of the hoist-adjacent-loads patch. I'm sorry for the
> delay since the last revision, but my performance testing has been
> blocked waiting for a fix to PR53487. I ended up applying a test
> version of
On Mon, 2012-06-04 at 08:45 -0500, William J. Schmidt wrote:
> Hi Richard,
>
> Here's a revision of the hoist-adjacent-loads patch. I'm sorry for the
> delay since the last revision, but my performance testing has been
> blocked waiting for a fix to PR53487. I ended up applying a test
> version
On Mon, Jun 04, 2012 at 08:45:20AM -0500, William J. Schmidt wrote:
> 2012-06-04 Bill Schmidt
>
> * opts.c: Add -fhoist_adjacent_loads to -O2 and above.
The option name has hyphens instead of underscores in it, so the above is
wrong.
> --- gcc/common.opt(revision 187805)
> +++ gcc/c
Hi Richard,
Here's a revision of the hoist-adjacent-loads patch. I'm sorry for the
delay since the last revision, but my performance testing has been
blocked waiting for a fix to PR53487. I ended up applying a test
version of the patch to 4.7 and ran performance numbers with that
instead, with n
On Wed, 2012-05-23 at 13:25 +0200, Richard Guenther wrote:
> On Tue, 22 May 2012, William J. Schmidt wrote:
>
> > Here's a revision of the hoist-adjacent-loads patch. Besides hopefully
> > addressing all your comments, I added a gate of at least -O2 for this
> > transformation. Let me know if yo
On Tue, 22 May 2012, William J. Schmidt wrote:
> Here's a revision of the hoist-adjacent-loads patch. Besides hopefully
> addressing all your comments, I added a gate of at least -O2 for this
> transformation. Let me know if you prefer a different minimum opt
> level.
>
> I'm still running SPEC
Here's a revision of the hoist-adjacent-loads patch. Besides hopefully
addressing all your comments, I added a gate of at least -O2 for this
transformation. Let me know if you prefer a different minimum opt
level.
I'm still running SPEC tests to make sure there are no regressions when
opening th
On Mon, 2012-05-21 at 14:17 +0200, Richard Guenther wrote:
> On Thu, May 3, 2012 at 4:33 PM, William J. Schmidt
> wrote:
> > This patch was posted for comment back in February during stage 4. It
> > addresses a performance issue noted in the EEMBC routelookup benchmark
> > on a common idiom:
> >
On Thu, May 3, 2012 at 4:33 PM, William J. Schmidt
wrote:
> This patch was posted for comment back in February during stage 4. It
> addresses a performance issue noted in the EEMBC routelookup benchmark
> on a common idiom:
>
> if (...)
> x = y->left;
> else
> x = y->right;
>
> If the two
Ping.
Thanks,
Bill
On Thu, 2012-05-03 at 09:33 -0500, William J. Schmidt wrote:
> This patch was posted for comment back in February during stage 4. It
> addresses a performance issue noted in the EEMBC routelookup benchmark
> on a common idiom:
>
> if (...)
> x = y->left;
> else
>
On 05/03/2012 12:11 PM, William J. Schmidt wrote:
However, from the wiki page I see: "A speculative load which has its
results thrown away are considered to not have changed the semantics of
the program, and are therefore allowed." That seems to cover the case
here: the load is hoisted, but i
On Thu, 2012-05-03 at 11:44 -0600, Jeff Law wrote:
> On 05/03/2012 10:47 AM, William J. Schmidt wrote:
> >>
> > Yes and no. What's important is that you don't want to introduce page
> > faults (or less urgently, cache misses) by speculating the load. So the
> > patch is currently extremely cons
On 05/03/2012 10:47 AM, William J. Schmidt wrote:
Yes and no. What's important is that you don't want to introduce page
faults (or less urgently, cache misses) by speculating the load. So the
patch is currently extremely constrained, and likely will always stay
that way. Only fields that are
On Thu, 2012-05-03 at 09:40 -0600, Jeff Law wrote:
> On 05/03/2012 08:33 AM, William J. Schmidt wrote:
> > This patch was posted for comment back in February during stage 4. It
> > addresses a performance issue noted in the EEMBC routelookup benchmark
> > on a common idiom:
> >
> >if (...)
> >
On 05/03/2012 08:33 AM, William J. Schmidt wrote:
This patch was posted for comment back in February during stage 4. It
addresses a performance issue noted in the EEMBC routelookup benchmark
on a common idiom:
if (...)
x = y->left;
else
x = y->right;
If the two loads can be hoi
This patch was posted for comment back in February during stage 4. It
addresses a performance issue noted in the EEMBC routelookup benchmark
on a common idiom:
if (...)
x = y->left;
else
x = y->right;
If the two loads can be hoisted out of the if/else, the if/else can be
replaced by
21 matches
Mail list logo
