On Wed, 2012-07-25 at 13:39 -0600, Sandra Loosemore wrote:
> On 07/17/2012 05:22 AM, Richard Guenther wrote:
> > On Wed, Jul 4, 2012 at 6:35 PM, Sandra Loosemore
> > wrote:
> >>
> >> Ping? Original post with patch is here:
> >>
> >> http://gcc.gnu.org/ml/gcc-patches/2012-06/msg00319.html
> >
> >
On 07/17/2012 05:22 AM, Richard Guenther wrote:
On Wed, Jul 4, 2012 at 6:35 PM, Sandra Loosemore
wrote:
Ping? Original post with patch is here:
http://gcc.gnu.org/ml/gcc-patches/2012-06/msg00319.html
Can you update the patch and numbers based on what Bill did for
straight-line strength re
On Wed, Jul 4, 2012 at 6:35 PM, Sandra Loosemore
wrote:
> On 06/05/2012 10:34 AM, Sandra Loosemore wrote:
>
>> 2012-06-05 Sandra Loosemore
>>
>> gcc/
>> * tree-ssa-loop-ivopts.c (comp_cost): Make complexity field
>> signed.
>> Update comments to indicate this is for addres
Hi,
For the following code change,
@@ -4212,11 +4064,6 @@ get_computation_cost_at (struct ivopts_d
cost.cost += adjust_setup_cost (data,
add_cost (TYPE_MODE (ctype), speed));
- /* Having offset does not affect runtime cost in case it is added to
- sy
On 06/05/2012 10:34 AM, Sandra Loosemore wrote:
2012-06-05 Sandra Loosemore
gcc/
* tree-ssa-loop-ivopts.c (comp_cost): Make complexity field signed.
Update comments to indicate this is for addressing mode complexity.
(new_cost): Make signedness of parameters mat
On 06/06/2012 02:29 AM, Richard Guenther wrote:
Pre-computing and caching things is to avoid creating RTXen over and over.
As you have discarded this completely did you try to measure the cost
of doing so in terms of produced garbage and compile-time cost? Did you
consider changing the target i
On Sun, 2012-06-10 at 13:50 -0400, Hans-Peter Nilsson wrote:
> On Sun, 10 Jun 2012, Oleg Endo wrote:
> > I've tried some of the cases mentioned in
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50749
> > with Sandra's patch applied. Unfortunately it didn't help much.
>
> But thanks for checking!
On Sun, 10 Jun 2012, Oleg Endo wrote:
> I've tried some of the cases mentioned in
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50749
> with Sandra's patch applied. Unfortunately it didn't help much.
But thanks for checking!
> There
> seem to be other things going wrong with auto-inc-dec.
Yeah
On Fri, 2012-06-08 at 22:33 -0400, Hans-Peter Nilsson wrote:
> On Tue, 5 Jun 2012, Sandra Loosemore wrote:
>
> > (1) While the address cost computation is assuming in some situations
> > that pre/post increment/decrement addressing will be used if
> > supported by the target, it isn't actually usi
On Tue, 5 Jun 2012, Sandra Loosemore wrote:
> (1) While the address cost computation is assuming in some situations
> that pre/post increment/decrement addressing will be used if
> supported by the target, it isn't actually using the target's address
> cost for such forms -- instead, just the cost
Hi,
> > (7) If the computed address cost turns out to be 0, the current code
> > (for some unknown reason) is turning that into 1, which can screw up
> > the relative costs of address computations vs other operations like
> > addition.
> >
> > I've come up with the attached patch to try to fix the
On Tue, Jun 5, 2012 at 6:34 PM, Sandra Loosemore
wrote:
> My colleagues and I have been working on the GCC port for the Qualcomm
> Hexagon. Along the way I noticed that we were getting poor results
> from the ivopts pass no matter how we adjusted the target-specific RTX
> costs. In many cases iv
12 matches
Mail list logo
