Re: RFC: PATCH to consider MAX_OFILE_ALIGNMENT for targetm.absolute_biggest_alignment

[Jason Merrill <jason@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 1382 bytes --]

On Tue, Sep 13, 2016 at 6:42 AM, Bernd Schmidt <bschmidt@redhat.com> wrote:
> On 09/12/2016 08:58 PM, Jason Merrill wrote:
>>
>> TARGET_ABSOLUTE_BIGGEST_ALIGNMENT is documented to be the largest
>> alignment possible for any type or variable, and defaults to
>> BIGGEST_ALIGNMENT.  But MAX_OFILE_ALIGNMENT is typically much larger
>> than BIGGEST_ALIGNMENT, and is documented as the limit for __attribute
>> ((aligned)).  Shouldn't it be considered in the default for
>> absolute_biggest_alignment?  But if we make that change, I expect that
>> your ACCEL_COMPILER streamer-in change would become a no-op.  What was
>> that change intended to accomplish?  I'm not finding anything about it
>> in gcc-patches.
>
> https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00003.html
>
> Its only purpose is to limit alignments when offloading to a different
> target. You may be right about having to use MAX_OFILE_ALIGNMENT; I suppose
> defining it to 64 on nvptx would still work.

That might be problematic; looking in nvptx I see

/* Copied from elf.h and other places.  We'd otherwise use
   BIGGEST_ALIGNMENT and fail a number of testcases.  */
#define MAX_OFILE_ALIGNMENT (32768 * 8)

But we could define TARGET_ABSOLUTE_BIGGEST_ALIGNMENT on nvptx instead
of on x86; is this OK?

I'm still not sure why you need an alignment cap on nvptx, but I'm not
going to worry about it anymore.  :)

[-- Attachment #2: absolute.diff --]
[-- Type: text/plain, Size: 2412 bytes --]

commit 9989c16cd646d017683e9b879c700c18f9aa0e8a
Author: Jason Merrill <jason@redhat.com>
Date:   Mon Sep 12 14:48:43 2016 -0400

    * target.def (absolute_biggest_alignment): Consider MAX_OFILE_ALIGNMENT.
    
    * config/i386/i386.c: Don't define TARGET_ABSOLUTE_BIGGEST_ALIGNMENT.
    * config/nvptx/nvptx.h (TARGET_ABSOLUTE_BIGGEST_ALIGNMENT): Define it.

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 051fddb..9c2c6c4 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -50730,9 +50730,6 @@ ix86_addr_space_zero_address_valid (addr_space_t as)
 #define TARGET_OFFLOAD_OPTIONS \
   ix86_offload_options
 
-#undef TARGET_ABSOLUTE_BIGGEST_ALIGNMENT
-#define TARGET_ABSOLUTE_BIGGEST_ALIGNMENT 512
-
 #undef TARGET_OPTAB_SUPPORTED_P
 #define TARGET_OPTAB_SUPPORTED_P ix86_optab_supported_p
 
diff --git a/gcc/config/nvptx/nvptx.h b/gcc/config/nvptx/nvptx.h
index 381269e..5172b08 100644
--- a/gcc/config/nvptx/nvptx.h
+++ b/gcc/config/nvptx/nvptx.h
@@ -52,6 +52,7 @@
 #define FUNCTION_BOUNDARY 32
 #define BIGGEST_ALIGNMENT 64
 #define STRICT_ALIGNMENT 1
+#define TARGET_ABSOLUTE_BIGGEST_ALIGNMENT 64
 
 #define MAX_STACK_ALIGNMENT (1024 * 8)
 
diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
index dc5bcd6..edb0fc8 100644
--- a/gcc/doc/tm.texi
+++ b/gcc/doc/tm.texi
@@ -1011,7 +1011,7 @@ just the biggest alignment that, when violated, may cause a fault.
 @deftypevr {Target Hook} HOST_WIDE_INT TARGET_ABSOLUTE_BIGGEST_ALIGNMENT
 If defined, this target hook specifies the absolute biggest alignment
 that a type or variable can have on this machine, otherwise,
-@code{BIGGEST_ALIGNMENT} is used.
+@code{MAX (BIGGEST_ALIGNMENT, MAX_OFILE_ALIGNMENT)} is used.
 @end deftypevr
 
 @defmac MALLOC_ABI_ALIGNMENT
diff --git a/gcc/target.def b/gcc/target.def
index 8509e7d..1c9fb5e 100644
--- a/gcc/target.def
+++ b/gcc/target.def
@@ -1931,8 +1931,8 @@ DEFHOOKPOD
 (absolute_biggest_alignment,
  "If defined, this target hook specifies the absolute biggest alignment\n\
 that a type or variable can have on this machine, otherwise,\n\
-@code{BIGGEST_ALIGNMENT} is used.",
- HOST_WIDE_INT, BIGGEST_ALIGNMENT)
+@code{MAX (BIGGEST_ALIGNMENT, MAX_OFILE_ALIGNMENT)} is used.",
+ HOST_WIDE_INT, MAX (BIGGEST_ALIGNMENT, MAX_OFILE_ALIGNMENT))
 
 /* Allow target specific overriding of option settings after options have
   been changed by an attribute or pragma or when it is reset at the