[Bug other/103095] New: Option to force no overalignment

[Bug other/103095] New: Option to force no overalignment

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103095

            Bug ID: 103095
           Summary: Option to force no overalignment
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: other
          Assignee: unassigned at gcc dot gnu.org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

Consider gdb test-case gdb/testsuite/gdb.arch/i386-avx.c.

It contains assembly doing:
...
  asm ("vmovaps 0(%0), %%ymm0\n\t"
       "vmovaps 32(%0), %%ymm1\n\t"
       "vmovaps 64(%0), %%ymm2\n\t"
       "vmovaps 96(%0), %%ymm3\n\t"
       "vmovaps 128(%0), %%ymm4\n\t"
       "vmovaps 160(%0), %%ymm5\n\t"
       "vmovaps 192(%0), %%ymm6\n\t"
       "vmovaps 224(%0), %%ymm7\n\t"
       : /* no output operands */
       : "r" (data)
       : "xmm0", "xmm1", "xmm2", "xmm3", "xmm4", "xmm5", "xmm6", "xmm7");
...
where data is an v8sf_t array, which is defined as:
...
typedef struct {
  float f[8];
} v8sf_t;
...

The vmovaps insn requires the memory operand to be 32-byte aligned, but the
data variable is required to be only float (4 byte) aligned.

However, the test-case passes for me, with a variety of gcc compilers for 4.8.5
to 11.2.1, because the actual alignment turns out to be sufficient.

But when running with clang it happens to fail because the actual alignment
turns out to be not sufficient.

It would be nice if we'd have a gcc compiler option that flushes out these
problems deterministically, by ensuring that variables have the required
alignment, but not more than that.

That is, say we have a float variable f of size 4 and alignment 4.  We'd want
to allocate 8 bytes for it, 8-byte aligned, and then place the variable in the
second half.  That way we've ensured that the variable is 4-byte aligned, but
not 8-byte aligned.

This may require changes in compiler and/or assembler and/or linker.

[Bug target/103095] Option to force no overalignment

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103095

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ABI
             Target|                            |x86_64
          Component|other                       |target

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I think the ABI actually requires this to be aligned to 32 byte.
clang might not be following the ABI.

[Bug target/103095] Option to force no overalignment

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103095

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
   AMD x86-64 psABI says that variables with array type larger than 15 bytes
   must be aligned to 16 byte boundaries.


There is already an option:
https://gcc.gnu.org/onlinedocs/gcc-11.2.0/gcc/x86-Options.html#index-malign-data-1
-malign-data=type
Control how GCC aligns variables. Supported values for type are ‘compat’ uses
increased alignment value compatible uses GCC 4.8 and earlier, ‘abi’ uses
alignment value as specified by the psABI, and ‘cacheline’ uses increased
alignment value to match the cache line size. ‘compat’ is the default.


You just need to supply -mabi-data=abi in this case if you want to disable over
aligning of things.

Other than that there is nothing to be done in GCC; it is up to the linker and
assembler to do the layout really.

The option was added in GCC 5 by r5-5887.

[Bug target/103095] Option to force no overalignment

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103095

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |---
   Last reconfirmed|                            |2021-11-07
             Target|x86_64                      |

--- Comment #3 from Tom de Vries <vries at gcc dot gnu.org> ---
This is not an x86_64-specific feature request, so removing the x86_64 from the
target field.

Thanks for pointing out -malign-data=abi, that's interesting.

I think though that it doesn't entirely match the feature request I've
described here.

Let's call the new one -fprecise-align for the moment.  It may be that
-fprecise-align should imply -malign-data=abi, I'm not sure, but for the
purposes of this discussion, I'll assume not.

AFAIU, the -malign-data=abi option has the effect that the compiler doesn't
require more alignment than required by the abi (which is one interpretation of
no overalignment).

The additional idea of this feature request is that the toolchain guarantees
that if some alignment is required, the actual address fits that alignment, but
not a greater alignment (which is another interpretation of no overalignment. 
Perhaps there's a better term for what I'm describing here?).

To be more concrete, take a float var, according to abi: size 4, alignment 4.

If we use -malign-data=abi and the variable at runtime is found at address 0x8,
we consider that the option is obeyed.

In contrast, if we use -malign=abi and -fprecise-align, and the variable at
runtime is found at address 0x8, we consider that the latter option is not
obeyed.

[Bug target/103095] Option to force no overalignment

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103095

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |UNCONFIRMED
     Ever confirmed|1                           |0

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #3)
> In contrast, if we use -malign=abi and -fprecise-align, and the variable at
> runtime is found at address 0x8, we consider that the latter option is not
> obeyed.


The original issue referenced in this bug was really fixed with
-malign-data=abi.


The more complex issue here is that "over alignment" is something which might
be the just does not make sense as an option to be provided.

Stack will need be reunaligned at runtime, I have to wonder if this is even a
good thing to do and can be represented in dwarf2 ...