This is an archive of the discontinued LLVM Phabricator instance.

[GlobalMerge] Don't merge dllexport globals
ClosedPublic

Authored by mstorsjo on Jan 16 2018, 12:51 PM.

Diff Detail

Repository
rL LLVM

Event Timeline

mstorsjo created this revision.Jan 16 2018, 12:51 PM

Why not only disable merging of dllexport variables (in GlobalMerge::doInitialization, where we already disable it on various kinds of variables), instead of all variables?

Why not only disable merging of dllexport variables (in GlobalMerge::doInitialization, where we already disable it on various kinds of variables), instead of all variables?

That probably works as well (or even trying to preserve the attribute?). I'll give it a try.

mstorsjo updated this revision to Diff 130490.Jan 18 2018, 1:36 PM
mstorsjo retitled this revision from [ARM] Don't merge global externals for windows to [GlobalMerge] Don't merge dllexport globals.
mstorsjo edited the summary of this revision. (Show Details)

Changed to explicitly check for the dllexport attribute.

Can you add a test case to ensure that it still triggers for non-dllexport cases with this target?

mstorsjo updated this revision to Diff 130562.Jan 18 2018, 11:23 PM

Added a testcase to show that normal globals still are merged.

Ping @john.brawn and @compnerd - does it look good to you now?

Wouldn't it be possible to merge multiple dllexport globals?

@x = dllexport global i32 0, align 4
@y = dllexport global i32 0, align 4
@z = global i32 0, align 4
@a = global i32 0, align 4

could still merge into:

@x = dllexport global i32 0, align 4
@z = global i32 0, align 4

even though technically we should be able to merge all of that into a single global and preserve the dllexport attribute.

Wouldn't it be possible to merge multiple dllexport globals?

@x = dllexport global i32 0, align 4
@y = dllexport global i32 0, align 4
@z = global i32 0, align 4
@a = global i32 0, align 4

could still merge into:

@x = dllexport global i32 0, align 4
@z = global i32 0, align 4

even though technically we should be able to merge all of that into a single global and preserve the dllexport attribute.

It could be doable, but it's rather much work - way more than this patch at least.

I've looked at what's missing - it'd require adding the dllstorage enum/field from GlobalValue into GlobalAlias (not sure if this requires extending the bitcode format), hook up GlobalAlias to the emitLinkerFlagsForGlobal function. I'd like to have the bug fixed in 6.0 as well, and this feels more and more out of scope for backporting.

IMO it'd be better to go for the approach of this patch first and backport that, and then look at maybe adding dllstorage to GlobalAlias for trunk after that, if actually doable.

compnerd accepted this revision.Jan 23 2018, 9:13 PM

That sounds reasonable. Please file PRs for the follow up work to enable the global merge for the dll export case.

This revision is now accepted and ready to land.Jan 23 2018, 9:13 PM
This revision was automatically updated to reflect the committed changes.
mstorsjo added a subscriber: hans.Jan 23 2018, 10:44 PM

@hans - can we backport this to the 6.0 branch? The usecase it fixes is "compiling Qt for Windows on ARM" (which previously fails when building with -O3). The fix in SVN r323307 probably requires merging SVN r322900 as well, to go without conflicts - it's a trivial testcase touch-up.

hans added a comment.Jan 24 2018, 7:55 AM

@hans - can we backport this to the 6.0 branch? The usecase it fixes is "compiling Qt for Windows on ARM" (which previously fails when building with -O3). The fix in SVN r323307 probably requires merging SVN r322900 as well, to go without conflicts - it's a trivial testcase touch-up.

Merged in r323337.