Re: i386/asm-4 test: use amd64's natural addressing mode on all OSs
On Thu, Aug 15, 2019 at 3:47 PM Alexandre Oliva wrote: > > On Aug 15, 2019, Uros Bizjak 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.
Re: i386/asm-4 test: use amd64's natural addressing mode on all OSs
On Aug 15, 2019, Uros Bizjak 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. -- Alexandre Oliva, freedom fighter he/him https://FSFLA.org/blogs/lxo Be the change, be Free! FSF Latin America board member GNU Toolchain EngineerFree Software Evangelist Hay que enGNUrecerse, pero sin perder la terGNUra jamás - Che GNUevara
Re: i386/asm-4 test: use amd64's natural addressing mode on all OSs
On Thu, Aug 15, 2019 at 3:01 PM Alexandre Oliva wrote: > > On Aug 15, 2019, Uros Bizjak wrote: > > > On Thu, Aug 15, 2019 at 1:39 PM Alexandre Oliva 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.
Re: i386/asm-4 test: use amd64's natural addressing mode on all OSs
On Aug 15, 2019, Uros Bizjak wrote: > On Thu, Aug 15, 2019 at 1:39 PM Alexandre Oliva 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. -- Alexandre Oliva, freedom fighter he/him https://FSFLA.org/blogs/lxo Be the change, be Free! FSF Latin America board member GNU Toolchain EngineerFree Software Evangelist Hay que enGNUrecerse, pero sin perder la terGNUra jamás - Che GNUevara
Re: i386/asm-4 test: use amd64's natural addressing mode on all OSs
On Thu, Aug 15, 2019 at 1:39 PM Alexandre Oliva 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.
i386/asm-4 test: use amd64's natural addressing mode on all OSs
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(-)
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));
--
Alexandre Oliva, freedom fighter he/him https://FSFLA.org/blogs/lxo
Be the change, be Free! FSF Latin America board member
GNU Toolchain EngineerFree Software Evangelist
Hay que enGNUrecerse, pero sin perder la terGNUra jamás - Che GNUevara
