On Wed, Apr 25, 2012 at 6:23 AM, Ulrich Weigand wrote:
> Andreas Krebbel wrote:
>
>> 2011-11-17 Andreas Krebbel
>>
>> * reload.c (find_reloads): Change the loop nesting when trying an
>> alternative with swapped operands.
>
> This is OK.
>
This caused:
http://gcc.gnu.org/bugzilla/
Andreas Krebbel wrote:
> 2011-11-17 Andreas Krebbel
>
> * reload.c (find_reloads): Change the loop nesting when trying an
> alternative with swapped operands.
This is OK.
Thanks,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@d
On Mon, Apr 23, 2012 at 7:04 PM, Ulrich Weigand wrote:
> Uros Bizjak wrote:
>
>> I don't have any problems with proposed order, but in my failed
>> attempt to convert x86 to post-reload compare elimination,
>> constrain_operands failed to recognize generated combined add+compare
>> pattern, when c
Uros Bizjak wrote:
> I don't have any problems with proposed order, but in my failed
> attempt to convert x86 to post-reload compare elimination,
> constrain_operands failed to recognize generated combined add+compare
> pattern, when commutative matched operands were swapped (e.g. the
> perfectly
On Mon, Apr 23, 2012 at 5:14 PM, Ulrich Weigand wrote:
>> > 2011-11-17 Andreas Krebbel
>> >
>> > * reload.c (find_reloads): Change the loop nesting when trying an
>> > alternative with swapped operands.
>>
>> I would just like to point out that constran_operands will have
>> problems t
Uros Bizjak wrote:
> > 2011-11-17 Andreas Krebbel
> >
> > * reload.c (find_reloads): Change the loop nesting when trying an
> > alternative with swapped operands.
>
> I would just like to point out that constran_operands will have
> problems to re-recognize alternative with swapped comm
Hello!
> 2011-11-17 Andreas Krebbel
>
> * reload.c (find_reloads): Change the loop nesting when trying an
> alternative with swapped operands.
I would just like to point out that constran_operands will have
problems to re-recognize alternative with swapped commutative
operands. The
Hi,
I've re-tested the patch from:
http://gcc.gnu.org/ml/gcc-patches/2011-11/msg01819.html
on s390x and x86_64.
Ok for mainline?
Bye,
-Andreas-
> I understand your concern and the patch indeed will have an impact on the
> generated code of probably several back-ends. But with entering stage 3 the
> backend maintainers anyway are supposed to have a closer look at
> regressions.
Yes, that's why risking to introduce more of them isn't the be
On 11/16/2011 06:53 AM, Jeff Law wrote:
> I'd ask the meta question, is there a compelling reason to push this
> patch into the tree now? My obvious concern is that this change
> potentially effects every target and twiddles one of GCC's most
> sensitive areas. Even if the patch is sound it's the
On 11/15/2011 11:31 PM, Maxim Kuvyrkov wrote:
> I have eye-balled this patch for good half-an-hour and couldn't poke any
> holes in it. I can't approve this patch, but below are some review comments.
> Mostly these are suggested comments to make reload easier to understand for
> future generat
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/15/11 15:31, Maxim Kuvyrkov wrote:
> On 15/11/2011, at 6:21 AM, Andreas Krebbel wrote:
>>
>> Bootstrapped on s390x, x86_64 and PPC64. No regressions
>>
>> Ok for mainline?
>
> Good portion of the code you're changing was written by Richard K.
On 15/11/2011, at 6:21 AM, Andreas Krebbel wrote:
> Hi,
>
> find_reloads currently loops over all alternatives in an insn and
> restarts the whole process after swapping commutative operands. This
> together with the early exit for a perfectly matching alternative
> leads to an behavior which do
13 matches
Mail list logo
