* RFC: PATCH to consider MAX_OFILE_ALIGNMENT for targetm.absolute_biggest_alignment
@ 2016-09-12 19:00 Jason Merrill
2016-09-13 11:03 ` Bernd Schmidt
0 siblings, 1 reply; 5+ messages in thread
From: Jason Merrill @ 2016-09-12 19:00 UTC (permalink / raw)
To: Bernd Schmidt; +Cc: gcc-patches List
[-- Attachment #1: Type: text/plain, Size: 563 bytes --]
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.
Jason
[-- Attachment #2: absolute.diff --]
[-- Type: text/plain, Size: 1995 bytes --]
commit a00ddb6492a784c192a19262780e734569866adb
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.
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/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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: RFC: PATCH to consider MAX_OFILE_ALIGNMENT for targetm.absolute_biggest_alignment
2016-09-12 19:00 RFC: PATCH to consider MAX_OFILE_ALIGNMENT for targetm.absolute_biggest_alignment Jason Merrill
@ 2016-09-13 11:03 ` Bernd Schmidt
2016-09-13 14:27 ` Jason Merrill
0 siblings, 1 reply; 5+ messages in thread
From: Bernd Schmidt @ 2016-09-13 11:03 UTC (permalink / raw)
To: Jason Merrill; +Cc: gcc-patches List
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.
Bernd
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: RFC: PATCH to consider MAX_OFILE_ALIGNMENT for targetm.absolute_biggest_alignment
2016-09-13 11:03 ` Bernd Schmidt
@ 2016-09-13 14:27 ` Jason Merrill
2016-09-13 14:34 ` Bernd Schmidt
0 siblings, 1 reply; 5+ messages in thread
From: Jason Merrill @ 2016-09-13 14:27 UTC (permalink / raw)
To: Bernd Schmidt; +Cc: gcc-patches List
[-- 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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: RFC: PATCH to consider MAX_OFILE_ALIGNMENT for targetm.absolute_biggest_alignment
2016-09-13 14:27 ` Jason Merrill
@ 2016-09-13 14:34 ` Bernd Schmidt
2016-09-14 16:43 ` Thomas Schwinge
0 siblings, 1 reply; 5+ messages in thread
From: Bernd Schmidt @ 2016-09-13 14:34 UTC (permalink / raw)
To: Jason Merrill; +Cc: gcc-patches List, Thomas Schwinge, Nathan Sidwell
On 09/13/2016 04:24 PM, Jason Merrill wrote:
> But we could define TARGET_ABSOLUTE_BIGGEST_ALIGNMENT on nvptx instead
> of on x86; is this OK?
That's what I had in mind. It would be good if Thomas or Nathan could
give this patch a spin, I'm not currently really set up for it. But it
looks like a reasonable try to me.
> I'm still not sure why you need an alignment cap on nvptx, but I'm not
> going to worry about it anymore. :)
I think it was the cfgexpand machinery that uses dynamic allocations
when a variable has a bigger alignment than the stack, and you really
don't want these on ptx.
Bernd
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: RFC: PATCH to consider MAX_OFILE_ALIGNMENT for targetm.absolute_biggest_alignment
2016-09-13 14:34 ` Bernd Schmidt
@ 2016-09-14 16:43 ` Thomas Schwinge
0 siblings, 0 replies; 5+ messages in thread
From: Thomas Schwinge @ 2016-09-14 16:43 UTC (permalink / raw)
To: Bernd Schmidt, Jason Merrill; +Cc: gcc-patches List, Nathan Sidwell
[-- Attachment #1: Type: text/plain, Size: 1116 bytes --]
Hi!
On Tue, 13 Sep 2016 16:27:39 +0200, Bernd Schmidt <bschmidt@redhat.com> wrote:
> On 09/13/2016 04:24 PM, Jason Merrill wrote:
>
> > But we could define TARGET_ABSOLUTE_BIGGEST_ALIGNMENT on nvptx instead
> > of on x86; is this OK?
>
> That's what I had in mind. It would be good if Thomas or Nathan could
> give this patch a spin, I'm not currently really set up for it. But it
> looks like a reasonable try to me.
I'm happy to report that this patch doesn't cause any changes in test
results both for nvptx target testing, and for nvptx offloading testing.
But I have not examined in detail what it actually does ;-) -- currently
occupied with too much other work already.
> > I'm still not sure why you need an alignment cap on nvptx, but I'm not
> > going to worry about it anymore. :)
>
> I think it was the cfgexpand machinery that uses dynamic allocations
> when a variable has a bigger alignment than the stack, and you really
> don't want these on ptx.
It will be good to document that, next to the definition in
gcc/config/nvptx/nvptx.h maybe?
Grüße
Thomas
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2016-09-14 16:33 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-09-12 19:00 RFC: PATCH to consider MAX_OFILE_ALIGNMENT for targetm.absolute_biggest_alignment Jason Merrill
2016-09-13 11:03 ` Bernd Schmidt
2016-09-13 14:27 ` Jason Merrill
2016-09-13 14:34 ` Bernd Schmidt
2016-09-14 16:43 ` Thomas Schwinge
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).