public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "carlos at systemhalted dot org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/60925] [4.9/4.10 Regression] hppa: can't find a register in class 'R1_REGS' while reloading 'asm'
Date: Mon, 26 May 2014 11:34:00 -0000	[thread overview]
Message-ID: <bug-60925-4-TOu7LombZD@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-60925-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60925

--- Comment #8 from Carlos O'Donell <carlos at systemhalted dot org> ---
On Sun, May 25, 2014 at 2:30 PM, John David Anglin <dave.anglin@bell.net>
wrote:
> On 25-May-14, at 7:11 AM, aaro.koskinen at iki dot fi wrote:
>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60925
>>
>> --- Comment #6 from Aaro Koskinen <aaro.koskinen at iki dot fi> ---
>> Created attachment 32852
>>  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32852&action=edit
>> Simplified reproducer.
>>
>> I tried to make a simpler reproducer.
>
>
> Thanks for simplifying the test case.  The problem is now clear.
>
>>
>> $ hppa-linux-gnu-gcc pr60925.c -c -O2 -Wall -g -fPIC
>> pr60925.c: In function 'foo':
>> pr60925.c:6:9: error: can't find a register in class 'R1_REGS' while
>> reloading
>> 'asm'
>>         asm volatile(
>>         ^
>
> The problem is the argument "futex" used in the asm.  When generating PIC
> code, register
> %r1 is needed for position independent loads and stores from memory.
>
> In the test, both statements involving __lll_mutex_lock are needed to
> trigger the
> error.  Essentially, reload fails to handle the reloads needed for &lock
> because the
> asm clobbers %r1 and %r1 is needed for the reload.
>
> Possibly, reload should be able to do this because the reload insns should
> be emitted
> before %r1 is clobbered by the asm, but reload is complicated.

I consider this a defect in reload, but accept that a correct fix might be
hard.

> A better fix is to ensure that the futex argument is placed in a general
> register
> that is not clobbered by the asm.  This has to happen anyway.  For example,

Better is an adjective applied to a qlualifier.

Better for what?

Better for us because it's a faster fix? :-)

> static inline int __attribute__((always_inline))
> __lll_mutex_lock(int *futex, int private)
> {
>   register int *f asm ("r5") = futex;

I'm fine with this as a workaround, but let's call it what it is, a workaround.

>   ...
>
> The other fix is to not inline __lll_mutex_lock.  Then, one is sure that

No, the locks should absolutely be inlined for performance reasons.

> futex will be
> in %r26 on entry, and it can be copied to another general register without
> %r1 being
> needed.

In summary:
- We need to change all hppa asms that might clobber %r1 to use fixed
  registers to avoid reload bugs.
- In this particular case change the futex code to use another random
  register for the futex argument.

Is that about right?

Cheers,
Carlos.


  parent reply	other threads:[~2014-05-26 11:34 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-22 19:36 [Bug target/60925] New: [4.9 " aaro.koskinen at iki dot fi
2014-04-22 19:38 ` [Bug target/60925] " aaro.koskinen at iki dot fi
2014-04-22 19:39 ` aaro.koskinen at iki dot fi
2014-04-23  8:41 ` [Bug target/60925] [4.9/4.10 " rguenth at gcc dot gnu.org
2014-05-22 20:25 ` aaro.koskinen at iki dot fi
2014-05-23 18:01 ` aaro.koskinen at iki dot fi
2014-05-25 11:12 ` aaro.koskinen at iki dot fi
2014-05-25 18:31 ` dave.anglin at bell dot net
2014-05-26 11:34 ` carlos at systemhalted dot org [this message]
2014-07-16 13:28 ` jakub at gcc dot gnu.org
2014-10-30 10:40 ` [Bug target/60925] [4.9/5 " jakub at gcc dot gnu.org
2014-12-01 11:59 ` rguenth at gcc dot gnu.org
2015-01-21  6:03 ` law at redhat dot com
2015-01-29 14:38 ` law at redhat dot com
2015-05-25  4:59 ` carlos at redhat dot com

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-60925-4-TOu7LombZD@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).