i386/asm-4 test: use amd64's natural addressing mode on all OSs
diff mbox series

Message ID ork1beirot.fsf@lxoliva.fsfla.org
State New
Headers show
Series
  • i386/asm-4 test: use amd64's natural addressing mode on all OSs
Related show

Commit Message

Alexandre Oliva Aug. 15, 2019, 11:38 a.m. UTC
gcc.target/i386/asm-4.c uses amd64's natural PC-relative addressing
mode on a single platform, using the 32-bit absolute addressing mode
elsewhere.  There's no point in giving up amd64's natural addressing
mode and insisting on the 32-bit one when we're targeting amd64, and
having to make explicit exceptions for systems where that's found not
to work for whatever reason.  If we just use the best-suited way to
take the address of a function behind the compiler's back on each
target variant, we're less likely to hit unexpected failures.

Tested on x86_64-linux-gnu with unix{,-m32}.  Ok to install?


for  gcc/testsuite/ChangeLog

	* gcc.target/i386/asm-4.c: Use amd64 natural addressing mode
	on all __LP64__ targets.
---
 gcc/testsuite/gcc.target/i386/asm-4.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Uros Bizjak Aug. 15, 2019, 12:50 p.m. UTC | #1
On Thu, Aug 15, 2019 at 1:39 PM Alexandre Oliva <oliva@adacore.com> wrote:
>
> gcc.target/i386/asm-4.c uses amd64's natural PC-relative addressing
> mode on a single platform, using the 32-bit absolute addressing mode
> elsewhere.  There's no point in giving up amd64's natural addressing
> mode and insisting on the 32-bit one when we're targeting amd64, and
> having to make explicit exceptions for systems where that's found not
> to work for whatever reason.  If we just use the best-suited way to
> take the address of a function behind the compiler's back on each
> target variant, we're less likely to hit unexpected failures.
>
> Tested on x86_64-linux-gnu with unix{,-m32}.  Ok to install?

Perhaps we should use true absolute address:

--cut here--
Index: asm-4.c
===================================================================
--- asm-4.c     (revision 274504)
+++ asm-4.c     (working copy)
@@ -27,12 +27,10 @@
 void
 baz (void)
 {
-  /* Darwin loads 64-bit regions above the 4GB boundary so
-     we need to use this instead.  */
-#if defined (__LP64__) && defined (__MACH__)
-  __asm ("leaq foo(%%rip), %0" : "=r" (fn));
+#if defined (__LP64__)
+  __asm ("movabsq $foo, %0" : "=r" (fn));
 #else
-  __asm ("movl $foo, %k0" : "=r" (fn));
+  __asm ("movl $foo, %0" : "=r" (fn));
 #endif
   if (fn (2, 3, 4, 5) != 14)
     abort ();
--cut here--

Uros.
Alexandre Oliva Aug. 15, 2019, 1:01 p.m. UTC | #2
On Aug 15, 2019, Uros Bizjak <ubizjak@gmail.com> wrote:

> On Thu, Aug 15, 2019 at 1:39 PM Alexandre Oliva <oliva@adacore.com> wrote:

>> If we just use the best-suited way to
>> take the address of a function behind the compiler's back on each
>> target variant, we're less likely to hit unexpected failures.

> Perhaps we should use true absolute address:

But why?  Using absolute addresses is not relevant at all to the test.
We just need some means to take the address of foo without the
compiler's realizing we're doing so.
Uros Bizjak Aug. 15, 2019, 1:06 p.m. UTC | #3
On Thu, Aug 15, 2019 at 3:01 PM Alexandre Oliva <oliva@adacore.com> wrote:
>
> On Aug 15, 2019, Uros Bizjak <ubizjak@gmail.com> wrote:
>
> > On Thu, Aug 15, 2019 at 1:39 PM Alexandre Oliva <oliva@adacore.com> wrote:
>
> >> If we just use the best-suited way to
> >> take the address of a function behind the compiler's back on each
> >> target variant, we're less likely to hit unexpected failures.
>
> > Perhaps we should use true absolute address:
>
> But why?  Using absolute addresses is not relevant at all to the test.
> We just need some means to take the address of foo without the
> compiler's realizing we're doing so.

The immediate of lea is limited to +-2GB, so we have in effect
-mcmodel=medium. Using movabs would be OK for all code models.

Uros.
Alexandre Oliva Aug. 15, 2019, 1:46 p.m. UTC | #4
On Aug 15, 2019, Uros Bizjak <ubizjak@gmail.com> wrote:

> The immediate of lea is limited to +-2GB

... and we're talking about a code offset within a tiny translation
unit, with both reference and referenced address within the same
section.  It would be very surprising if the offset got up to 2KB, let
alone 2GB ;-)

The reason the testcase even mentions absolute addresses AFAICT is not
that it wishes to use them, it's that there's no portable way to use
PC-relative addresses on IA-32 (*), so the test gives up on platforms
that mandate PIC and goes with absolute addressing there.  I'm pretty
sure if it had a choice it would happily use PC-relative addressing,
even with a reasonably short range, if that was readily available...

(*) Something like 'call 1f; 1: popl %0; leal $foo-1b(%0), %0' is the
closest to widely available I'm aware of, but the '1f/1b' notation is
only available with GNU as AFAIK.
Uros Bizjak Aug. 15, 2019, 4:20 p.m. UTC | #5
On Thu, Aug 15, 2019 at 3:47 PM Alexandre Oliva <oliva@adacore.com> wrote:
>
> On Aug 15, 2019, Uros Bizjak <ubizjak@gmail.com> wrote:
>
> > The immediate of lea is limited to +-2GB
>
> ... and we're talking about a code offset within a tiny translation
> unit, with both reference and referenced address within the same
> section.  It would be very surprising if the offset got up to 2KB, let
> alone 2GB ;-)
>
> The reason the testcase even mentions absolute addresses AFAICT is not
> that it wishes to use them, it's that there's no portable way to use
> PC-relative addresses on IA-32 (*), so the test gives up on platforms
> that mandate PIC and goes with absolute addressing there.  I'm pretty
> sure if it had a choice it would happily use PC-relative addressing,
> even with a reasonably short range, if that was readily available...
>
> (*) Something like 'call 1f; 1: popl %0; leal $foo-1b(%0), %0' is the
> closest to widely available I'm aware of, but the '1f/1b' notation is
> only available with GNU as AFAIK.

Well, OK ... let's go ahead with your patch then.

Thanks,
Uros.

Patch
diff mbox series

diff --git a/gcc/testsuite/gcc.target/i386/asm-4.c b/gcc/testsuite/gcc.target/i386/asm-4.c
index b86801032bc4..69dd1d3df0bf 100644
--- a/gcc/testsuite/gcc.target/i386/asm-4.c
+++ b/gcc/testsuite/gcc.target/i386/asm-4.c
@@ -29,7 +29,7 @@  baz (void)
 {
   /* Darwin loads 64-bit regions above the 4GB boundary so
      we need to use this instead.  */
-#if defined (__LP64__) && defined (__MACH__)
+#if defined (__LP64__)
   __asm ("leaq foo(%%rip), %0" : "=r" (fn));
 #else
   __asm ("movl $foo, %k0" : "=r" (fn));