| 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 | expand |
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.
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.
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.
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.
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.
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));
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(-)