On Tue, Feb 7, 2012 at 11:00 AM, Uros Bizjak wrote:
>>> Hmm. Well, the only thing that's going to work for x86 is the
>>> double-compare
>>> elimination portion.
>>>
>>> If we want to use this pass for x86, then for 4.8 we should also fix the
>>> discrepancy between the compare-elim canonical
>
On Tue, Feb 7, 2012 at 11:48 AM, Richard Guenther
wrote:
(BTW: I think that the change to combine.c would be nice to have, to
find more other combine opportunities. I will propose the patch
separately.)
>>>
>>> Shouldn't there be a canonical order for parallels throughout the whole
On Tue, Feb 7, 2012 at 11:46 AM, Uros Bizjak wrote:
> On Tue, Feb 7, 2012 at 11:04 AM, Richard Guenther
> wrote:
>
>>> (BTW: I think that the change to combine.c would be nice to have, to
>>> find more other combine opportunities. I will propose the patch
>>> separately.)
>>
>> Shouldn't there be
On Tue, Feb 7, 2012 at 11:04 AM, Richard Guenther
wrote:
>> (BTW: I think that the change to combine.c would be nice to have, to
>> find more other combine opportunities. I will propose the patch
>> separately.)
>
> Shouldn't there be a canonical order for parallels throughout the whole
> compile
On Tue, Feb 7, 2012 at 11:00 AM, Uros Bizjak wrote:
> On Mon, Feb 6, 2012 at 10:30 PM, Uros Bizjak wrote:
>
>>> Hmm. Well, the only thing that's going to work for x86 is the
>>> double-compare
>>> elimination portion.
>>>
>>> If we want to use this pass for x86, then for 4.8 we should also fix
On Mon, Feb 6, 2012 at 10:30 PM, Uros Bizjak wrote:
>> Hmm. Well, the only thing that's going to work for x86 is the double-compare
>> elimination portion.
>>
>> If we want to use this pass for x86, then for 4.8 we should also fix the
>> discrepancy between the compare-elim canonical
>>
>> [(op
On Feb 6, 2012, at 12:59 PM, Richard Henderson wrote:
> And, really, we ought to come up with some trick to eliminate some of the
> redundancy in patterns in the md file too.
:-) That'd be awesome...
On Mon, Feb 6, 2012 at 9:59 PM, Richard Henderson wrote:
> On 02/05/2012 07:27 AM, Uros Bizjak wrote:
>> Hello!
>>
>> Attached patch enables post-reload compare optimization pass for x86 targets.
>
> Hmm. Well, the only thing that's going to work for x86 is the double-compare
> elimination portio
On 02/05/2012 07:27 AM, Uros Bizjak wrote:
> Hello!
>
> Attached patch enables post-reload compare optimization pass for x86 targets.
Hmm. Well, the only thing that's going to work for x86 is the double-compare
elimination portion.
If we want to use this pass for x86, then for 4.8 we should als
On Sun, Feb 5, 2012 at 6:27 PM, Steven Bosscher wrote:
>> PR target/28685
>> * config/i386/i386.c (TARGET_FLAGS_REGNUM): New.
>>
>
> Hmm, how is this (apparently new in 2011) TARGET_FLAGS_REGNUM
> different from the older targetm.fixed_condition_code_regs?
This is how backend enabl
On Sun, Feb 5, 2012 at 4:27 PM, Uros Bizjak wrote:
> 2012-02-05 Uros Bizjak
>
> PR target/28685
> * config/i386/i386.c (TARGET_FLAGS_REGNUM): New.
>
Hmm, how is this (apparently new in 2011) TARGET_FLAGS_REGNUM
different from the older targetm.fixed_condition_code_regs?
Ciao!
St
Hello!
Attached patch enables post-reload compare optimization pass for x86 targets.
As shown in following test, patch removes redundant compare:
--cut here--
int test(int a, int b)
{
int lt = a < b;
int eq = a == b;
if (lt)
return 1;
return eq;
}
--cut here--
gcc -O2 on x86_64, a c
12 matches
Mail list logo
