On Sat, Nov 12, 2016 at 8:36 AM, Evgeny Kudryashov wrote:
> On 2016-11-10 13:30, Bin.Cheng wrote:
>>
>> Hi,
>> I see the cost problem with your test now. When computing an address
>> type iv_use with a candidate, the computation consists of two parts,
>> for computation can be represented by addr
On 2016-11-10 13:30, Bin.Cheng wrote:
Hi,
I see the cost problem with your test now. When computing an address
type iv_use with a candidate, the computation consists of two parts,
for computation can be represented by addressing mode, it is done in
memory reference; for computation cannot be rep
On Wed, Nov 9, 2016 at 1:02 PM, Bin.Cheng wrote:
> On Thu, Nov 3, 2016 at 4:00 PM, Bin.Cheng wrote:
>> On Thu, Nov 3, 2016 at 1:35 PM, Evgeny Kudryashov
>> wrote:
>>> Hello,
>>>
>>> I'm facing the following problem related to ivopts. The problem is that GCC
>>> generates a lot of induction vari
On Thu, Nov 3, 2016 at 4:00 PM, Bin.Cheng wrote:
> On Thu, Nov 3, 2016 at 1:35 PM, Evgeny Kudryashov
> wrote:
>> Hello,
>>
>> I'm facing the following problem related to ivopts. The problem is that GCC
>> generates a lot of induction variables and as a result there is an
>> unnecessary increase
On Thu, Nov 3, 2016 at 1:35 PM, Evgeny Kudryashov wrote:
> Hello,
>
> I'm facing the following problem related to ivopts. The problem is that GCC
> generates a lot of induction variables and as a result there is an
> unnecessary increase of stack usage and register pressure.
>
> For instance, for
Hello,
I'm facing the following problem related to ivopts. The problem is that
GCC generates a lot of induction variables and as a result there is an
unnecessary increase of stack usage and register pressure.
For instance, for the attached testcase (tc_ivopts.c) GCC generates 26
induction va