[PATCH] D124654: [AIX] Handling the label alignment of a global variable with its multiple aliases.
Esme Yi via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Wed Jun 15 09:35:53 PDT 2022
Esme added inline comments.
================
Comment at: llvm/test/CodeGen/PowerPC/aix-alias-alignment.ll:39
+; ASM-NEXT: var3:
+; ASM-NEXT: .vbyte 4, L.._MergedGlobals+4
+; ASM-NEXT: .lglobl var2
----------------
shchenz wrote:
> This is not right as we allocate other space for var2/var3 which should be aliased to `_MergedGlobals`. `_MergedGlobals` has 8 bytes allocated in previous two `.vbyte`.
> You can check the symbol table after assembling the assembly, below is what I get on AIX:
> ```
> [7] m 0x00000034 .data 1 extern foo
> [8] a4 0x0000000c 0 0 SD DS 0 0
> [9] m 0x00000040 .data 1 unamex L.._MergedGlobals
> [10] a4 0x00000010 0 0 SD RW 0 0
> [11] m 0x00000048 .data 1 unamex var1
> [12] a4 0x00000009 0 0 LD RW 0 0
> [13] m 0x0000004c .data 1 unamex var2
> [14] a4 0x00000009 0 0 LD RW 0 0
> [15] m 0x0000004c .data 1 extern var3
> [16] a4 0x00000009 0 0 LD RW 0 0
> [17] m 0x00000050 .data 1 unamex L..base
> [18] a4 0x0000000c 0 0 SD RW 0 0
> [19] m 0x00000058 .data 1 unamex var4
> [20] a4 0x00000011 0 0 LD RW 0 0
> [21] m 0x00000058 .data 1 extern var5
> [22] a4 0x00000011 0 0 LD RW 0 0
> [23] m 0x0000005c .data 1 unamex TOC
> [24] a4 0x00000000 0 0 SD TC0 0 0
> [25] m 0x0000005c .data 1 unamex L.._MergedGlobals
> [26] a4 0x00000004 0 0 SD TC 0 0
> [27] m 0x00000060 .data 1 unamex L..base
> [28] a4 0x00000004 0 0 SD TC 0 0
> ```
>
> You can see that section `_MergedGlobals` now is 16 bytes but it should be 8 bytes and var1 are not aligned with `_MergedGlobals` too.
>
> I think for data-section enabled, the expected assembly generated from compiler should be like:
> ```assembly
> .csect L.._MergedGlobals[RW],2
> .align 2 # @_MergedGlobals
> var1:
> .vbyte 4, 1 # 0x1
> .lglobl var1
> var2:
> var3:
> .vbyte 4, 2 # 0x2
> .lglobl var2
> .globl var3
> .csect L..base[RW],2
> .align 2 # @base
> .vbyte 4, 1 # 0x1
> var4:
> var5:
> .vbyte 4, 2 # 0x2
> .lglobl var4
> .globl var5
> ```
>
> With above assembly, I get:
> ```
> [9] m 0x00000040 .data 1 unamex L.._MergedGlobals
> [10] a4 0x00000008 0 0 SD RW 0 0
> [11] m 0x00000040 .data 1 unamex var1
> [12] a4 0x00000009 0 0 LD RW 0 0
> [13] m 0x00000044 .data 1 unamex var2
> [14] a4 0x00000009 0 0 LD RW 0 0
> [15] m 0x00000044 .data 1 extern var3
> [16] a4 0x00000009 0 0 LD RW 0 0
> [17] m 0x00000048 .data 1 unamex L..base
> [18] a4 0x00000008 0 0 SD RW 0 0
> [19] m 0x0000004c .data 1 unamex var4
> [20] a4 0x00000011 0 0 LD RW 0 0
> [21] m 0x0000004c .data 1 extern var5
> [22] a4 0x00000011 0 0 LD RW 0 0
> [23] m 0x00000050 .data 1 unamex TOC
> [24] a4 0x00000000 0 0 SD TC0 0 0
> [25] m 0x00000050 .data 1 unamex L.._MergedGlobals
> [26] a4 0x00000004 0 0 SD TC 0 0
> [27] m 0x00000054 .data 1 unamex L..base
> [28] a4 0x00000004 0 0 SD TC 0 0
> ```
Thank you for your comments!
I doubt that AIX's assembly format can support such strict alignment requirements.
As you suggest, element values in a base AliaseeObject are not emitted under its label but its aliases' labels, which would solve the problem in my test case, but consider the following case, where should the third element value (.vbyte 4, 3) be emitted?
```
;; base has three elements and only the second one has alias.
@base = global <{ i32, i32, i32 }> <{ i32 1, i32 2, i32 3 }>, align 4
@var1 = internal alias i32, getelementptr inbounds (<{ i32, i32 }>, <{ i32, i32 }>* @base, i32 0, i32 1)
@var2 = alias i32, i32* @var1
```
Consider a more complex example:
```
base has 4 elements: { i32 1, i32 2, i32 3, i32 4 }, align 4
var1 is the alias to {i32 1, i32 2}
var2 is the alias to {i32 2, i32 3}
```
I have no idea what the assembly of this case should be in order to meet the correct values and alignment.
================
Comment at: llvm/test/CodeGen/PowerPC/aix-alias-alignment.ll:53
+
+; NOGVLABEL: # -- End function
+; NOGVLABEL-NEXT: .csect L.._MergedGlobals[RW],2
----------------
shchenz wrote:
> For data-section disabled case, the current patch also has `.vbyte` issue, however, even I changed the assembly like above, I still can not get right symbol table. I changed the assembly like:
> ```
> .csect .data[RW],2
> .align 2 # @_MergedGlobals
> L.._MergedGlobals:
> var1:
> .vbyte 4, 1 # 0x1
> .lglobl var1
> var2:
> var3:
> .vbyte 4, 2 # 0x2
> .lglobl var2
> .globl var3
> .align 2 # @base
> L..base:
> .vbyte 4, 1 # 0x1
> var4:
> var5:
> .vbyte 4, 2 # 0x2
> .lglobl var4
> .globl var5
> ```
>
> I get:
> ```
> [9] m 0x00000040 .data 1 unamex .data
> [10] a4 0x00000010 0 0 SD RW 0 0
> [11] m 0x00000040 .data 1 unamex var1
> [12] a4 0x00000009 0 0 LD RW 0 0
> [13] m 0x00000044 .data 1 unamex var2
> [14] a4 0x00000009 0 0 LD RW 0 0
> [15] m 0x00000044 .data 1 extern var3
> [16] a4 0x00000009 0 0 LD RW 0 0
> [17] m 0x0000004c .data 1 unamex var4
> [18] a4 0x00000009 0 0 LD RW 0 0
> [19] m 0x0000004c .data 1 extern var5
> [20] a4 0x00000009 0 0 LD RW 0 0
> [21] m 0x00000050 .data 1 unamex TOC
> [22] a4 0x00000000 0 0 SD TC0 0 0
> [23] m 0x00000050 .data 1 unamex L.._MergedGlobals
> [24] a4 0x00000004 0 0 SD TC 0 0
> [25] m 0x00000054 .data 1 unamex L..base
> [26] a4 0x00000004 0 0 SD TC 0 0
> ```
>
> You can see that, no way to change the content in `.data` section for var1/var2/var3, we only have TOC entry for `L.._MergedGlobals` but not associated to any SD/LD symbol in the `.data` section. If we want to support them, we may need to add TOC entry for var1/var2/var3/var4/var5 or find a way to make assembler generate two LD symbols to same location.
>
> I suggest in this patch, we only handle data-sections enabled case.
The missing linkage info caused the issue, ie. the directive `.globl` is not emitted for `private global` variables. I'm not sure whether the behavior is reasonable. However, it's out of this patch's scope and I'll investigate it as follow-up work.
Using `@_MergedGlobals = global <{ i32, i32 }> <{ i32 1, i32 2 }>, align 4` emits the directive `.globl _MergedGlobals`, which fixed the problem.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D124654/new/
https://reviews.llvm.org/D124654
More information about the llvm-commits
mailing list