> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
> Jiangning Liu
> Sent: Friday, February 17, 2012 5:53 PM
> To: gcc@gcc.gnu.org
> Subject: A problem about loop store motion
>
> Hi,
>
> For this small test case,
>
> int *l, *r;
> int test_f
On Sun, Feb 19, 2012 at 4:43 PM, Marc Glisse wrote:
> On Sun, 19 Feb 2012, Kumar, Venkataramanan wrote:
>
>> Sphinx3 benchmark segmented when built and ran with -Ofast and
>> -fprefecth-loop-arrays.
>
> [...]
>
>> In my case the register 367 is sNAN.
>
>
> -Ofast implies -ffast-math which implies
On Mon, Feb 20, 2012 at 9:46 AM, Jiangning Liu wrote:
>
>
>> -Original Message-
>> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
>> Jiangning Liu
>> Sent: Friday, February 17, 2012 5:53 PM
>> To: gcc@gcc.gnu.org
>> Subject: A problem about loop store motion
>>
>>
On 2012-02-18 14:38:01 +, James Courtier-Dutton wrote:
> Would it be useful to have some lib functions:
> remainder_2pi(x, &remainder) /* returns remainder of x / 2Pi */
> remainder_pi2(x, &remainder, "ient) /* returns remainder of x /
> (Pi/2) with a quotient returned so you can tell whe
> -Original Message-
> From: Richard Guenther [mailto:richard.guent...@gmail.com]
> Sent: Monday, February 20, 2012 4:58 PM
> To: gcc@gcc.gnu.org
> Cc: Kumar, Venkataramanan
> Subject: Re: [i386] Question about Constraint Modifier character in smaxdf3
> pattern.
>
> On Sun, Feb 19, 2012 a
Ping.
>>looks like an invalid transformation, but I suspect rather than setting
>>the CC register, the (*) insn is setting a pseudo (more accurate RTL
>>would be useful). There are some cases in ifcvt.c which check
>>targetm.small_register_classes_for_mode already, this is probably what
>>should be
On 02/14/2012 07:12 PM, Henderson, Stuart wrote:
>> spill_failure does return for asms since we don't want to ICE on bad
>> user code. That's all that's going on here.
>
> ahh, thanks.
>
>> It sounds like ifcvt needs to be fixed. Your example:
>>> block 44:
>>> set cc = x;
>>> set cc = y; (*)
>>>
Hello,
we've noticed that the loop optimizer sometimes inserts weirdly
inefficient code to compute the value of an induction variable
at the end of the loop.
As a test case stripped down to the core of the problem, consider:
int test (int start, int end)
{
int i;
for (i = start; i < end; i+
