> I agree with Vlad that we're better off with Andreas' patch than without,
> since
> computing addresses is going to be 99% of what reload/LRA needs to do.
>
> I also agree with Eric that some better commentary would be nice.
Ok. I've applied the following patch.
Bye,
-Andreas-
2014-03-24 A
On 03/18/2014 04:59 AM, Jakub Jelinek wrote:
> On Mon, Mar 17, 2014 at 03:24:14PM -0400, Vladimir Makarov wrote:
>> It is complicated. There is no guarantee that it is used only for
>> addresses. I need some time to think how to fix it.
>>
>> Meanwhile, you *should* commit the patch into the trun
On Mon, Mar 17, 2014 at 03:24:14PM -0400, Vladimir Makarov wrote:
> It is complicated. There is no guarantee that it is used only for
> addresses. I need some time to think how to fix it.
>
> Meanwhile, you *should* commit the patch into the trunk because it
> solves the real problem. And I can
On 2014-03-13, 7:37 AM, Andreas Krebbel wrote:
On 13/03/14 12:25, Richard Biener wrote:
On Thu, Mar 13, 2014 at 12:16 PM, Eric Botcazou wrote:
--- a/gcc/doc/md.texi
+++ b/gcc/doc/md.texi
@@ -4720,6 +4720,17 @@ Add operand 2 and operand 1, storing the result in
operand 0. All operands must hav
> > Then you should document that by stating that the pattern is guaranteed
> > to be invoked only for addresses (and may not clobber the condition
> > code).
> Ok, will do.
Thanks.
> > Hoping isn't sufficient IMO here, you need to rename/rework
> > emit_add3_insn and possibly stop the compiler i
On 14/03/14 11:02, Eric Botcazou wrote:
>> This would suggest that you can use the pattern also for performing a normal
>> add in case the condition code is not needed afterwards but this isn't
>> correct for s390 31 bit where an address calculation is actually something
>> different.
>
> Then you
> This would suggest that you can use the pattern also for performing a normal
> add in case the condition code is not needed afterwards but this isn't
> correct for s390 31 bit where an address calculation is actually something
> different.
Then you should document that by stating that the patter
On 13/03/14 12:25, Richard Biener wrote:
> On Thu, Mar 13, 2014 at 12:16 PM, Eric Botcazou wrote:
>>> --- a/gcc/doc/md.texi
>>> +++ b/gcc/doc/md.texi
>>> @@ -4720,6 +4720,17 @@ Add operand 2 and operand 1, storing the result in
>>> operand 0. All operands must have mode @var{m}. This can be used
On Thu, Mar 13, 2014 at 12:16 PM, Eric Botcazou wrote:
>> --- a/gcc/doc/md.texi
>> +++ b/gcc/doc/md.texi
>> @@ -4720,6 +4720,17 @@ Add operand 2 and operand 1, storing the result in
>> operand 0. All operands must have mode @var{m}. This can be used even on
>> two-address machines, by means of c
On 13/03/14 12:16, Eric Botcazou wrote:
>> --- a/gcc/doc/md.texi
>> +++ b/gcc/doc/md.texi
>> @@ -4720,6 +4720,17 @@ Add operand 2 and operand 1, storing the result in
>> operand 0. All operands must have mode @var{m}. This can be used even on
>> two-address machines, by means of constraints requi
> --- a/gcc/doc/md.texi
> +++ b/gcc/doc/md.texi
> @@ -4720,6 +4720,17 @@ Add operand 2 and operand 1, storing the result in
> operand 0. All operands must have mode @var{m}. This can be used even on
> two-address machines, by means of constraints requiring operands 1 and 0 to
> be the same locati
On Thu, Mar 13, 2014 at 10:24:13AM +0100, Andreas Krebbel wrote:
> --- a/gcc/doc/md.texi
> +++ b/gcc/doc/md.texi
> @@ -4720,6 +4720,17 @@ Add operand 2 and operand 1, storing the result in
> operand 0. All operands
> must have mode @var{m}. This can be used even on two-address machines, by
> m
Hi,
fixes the LRA problems described in:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60501
and
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57604
Bootstrapped and regtested on s390, s390x, and x86_64.
Ok?
Bye,
-Andreas-
2014-03-13 Andreas Krebbel
PR rtl-optimization/60501
*
13 matches
Mail list logo
