diff options
| author | Ben Gamari <bgamari.foss@gmail.com> | 2016-12-16 11:59:49 -0500 |
|---|---|---|
| committer | Ben Gamari <ben@smart-cactus.org> | 2016-12-16 11:59:51 -0500 |
| commit | 5bf344b7f4e1538fbc019896ae07ae3ec2a18207 (patch) | |
| tree | 903812e301a1fafe8d3f75b8b6a5943f1019c48a /compiler/nativeGen | |
| parent | c889df86d7bc9eb4cd53e38c81feecaf5f932678 (diff) | |
| download | haskell-5bf344b7f4e1538fbc019896ae07ae3ec2a18207.tar.gz | |
CLabel: Kill redundant UnitId argument from labelDynamic
It already has access to the current package's UnitId via the Module.
Edward Yang pointed out that there is one wrinkle, however: the
following invariant isn't true at all stages of compilation,
if I am compiling the module (this_mod :: Module), then
thisPackage dflags == moduleUnitId this_mod.
Specifically, this is only true after desugaring; it may be broken when
typechecking an indefinite signature.
However, it's safe to assume this in the native codegen. I've updated
Note to state this invariant more directly.
Test Plan: Validate
Reviewers: austin, ezyang, simonmar
Reviewed By: ezyang, simonmar
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2863
Diffstat (limited to 'compiler/nativeGen')
| -rw-r--r-- | compiler/nativeGen/PIC.hs | 16 |
1 files changed, 8 insertions, 8 deletions
diff --git a/compiler/nativeGen/PIC.hs b/compiler/nativeGen/PIC.hs index 2529f91de8..babceac4f0 100644 --- a/compiler/nativeGen/PIC.hs +++ b/compiler/nativeGen/PIC.hs @@ -241,7 +241,7 @@ howToAccessLabel dflags _ OSMinGW32 this_mod _ lbl -- If the target symbol is in another PE we need to access it via the -- appropriate __imp_SYMBOL pointer. - | labelDynamic dflags (thisPackage dflags) this_mod lbl + | labelDynamic dflags this_mod lbl = AccessViaSymbolPtr -- Target symbol is in the same PE as the caller, so just access it directly. @@ -259,7 +259,7 @@ howToAccessLabel dflags _ OSMinGW32 this_mod _ lbl -- howToAccessLabel dflags arch OSDarwin this_mod DataReference lbl -- data access to a dynamic library goes via a symbol pointer - | labelDynamic dflags (thisPackage dflags) this_mod lbl + | labelDynamic dflags this_mod lbl = AccessViaSymbolPtr -- when generating PIC code, all cross-module data references must @@ -283,7 +283,7 @@ howToAccessLabel dflags arch OSDarwin this_mod JumpReference lbl -- stack alignment is only right for regular calls. -- Therefore, we have to go via a symbol pointer: | arch == ArchX86 || arch == ArchX86_64 - , labelDynamic dflags (thisPackage dflags) this_mod lbl + , labelDynamic dflags this_mod lbl = AccessViaSymbolPtr @@ -292,7 +292,7 @@ howToAccessLabel dflags arch OSDarwin this_mod _ lbl -- not needed on x86_64 because Apple's new linker, ld64, generates -- them automatically. | arch /= ArchX86_64 - , labelDynamic dflags (thisPackage dflags) this_mod lbl + , labelDynamic dflags this_mod lbl = AccessViaStub | otherwise @@ -344,7 +344,7 @@ howToAccessLabel dflags arch os this_mod DataReference lbl | osElfTarget os = case () of -- A dynamic label needs to be accessed via a symbol pointer. - _ | labelDynamic dflags (thisPackage dflags) this_mod lbl + _ | labelDynamic dflags this_mod lbl -> AccessViaSymbolPtr -- For PowerPC32 -fPIC, we have to access even static data @@ -372,17 +372,17 @@ howToAccessLabel dflags arch os this_mod DataReference lbl howToAccessLabel dflags arch os this_mod CallReference lbl | osElfTarget os - , labelDynamic dflags (thisPackage dflags) this_mod lbl && not (gopt Opt_PIC dflags) + , labelDynamic dflags this_mod lbl && not (gopt Opt_PIC dflags) = AccessDirectly | osElfTarget os , arch /= ArchX86 - , labelDynamic dflags (thisPackage dflags) this_mod lbl && gopt Opt_PIC dflags + , labelDynamic dflags this_mod lbl && gopt Opt_PIC dflags = AccessViaStub howToAccessLabel dflags _ os this_mod _ lbl | osElfTarget os - = if labelDynamic dflags (thisPackage dflags) this_mod lbl + = if labelDynamic dflags this_mod lbl then AccessViaSymbolPtr else AccessDirectly |