Add -f[no-]direct-access-external-data to supersede -mpie-copy-relocations

[MaskRay]

Summary

GCC r218397 "x86-64: Optimize access to globals in PIE with copy reloc" made
-fpie code emit R_X86_64_PC32 to reference external data symbols by default.
Clang adopted -mpie-copy-relocations D19996 as a flexible alternative.

The name -mpie-copy-relocations can be improved [1] and does not capture the
idea that this option can apply to -fno-pic and -fpic [2], so this patch
introduces -f[no-]direct-access-external-data and makes -mpie-copy-relocations
their aliases for compatibility.

[1]
For

extern int var;
int get() { return var; }

if var is defined in another translation unit in the link unit, there is no copy
relocation.

[2]
-fno-pic -fno-direct-access-external-data is useful to avoid copy relocations.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65888
If a shared object is linked with -Bsymbolic or --dynamic-list and exports a
data symbol, normally the data symbol cannot be accessed by -fno-pic code
(because by default an absolute relocation is produced which will lead to a copy
relocation). -fno-direct-access-external-data can prevent copy relocations.

-fpic -fdirect-access-external-data can avoid GOT indirection. However, the
user should be responsible for defining var in another translation unit and link
with -Bsymbolic or --dynamic-list, otherwise the linker will error in a -shared
link. Generally the user has better tools for their goal but I want to mention that
this combination is valid.

On COFF, the behavior is like always -fdirect-access-external-data.
__declspec(dllimport) is needed to enable indirect access.

There is currently no plan to affect non-ELF behavior or -fpic behavior.

-fno-pic -fno-direct-access-external-data will be implemented in the subsequent patch.

GCC feature request https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98112

[tmsriram]

You said : "The name -mpie-copy-relocations is misleading [1] and does not capture the idea that this option can actually apply to all of -fno-pic,-fpie, ..."

Could you please clarify why this option needs to apply to -fno-pic? Here is what I tried with trunk clang:

extern int var;
int get() { return var; }

$ clang -S foo.c -o -
....
movl var, %eax
popq %rbp
...

With -fno-pic, this will never need to use -mpie-copy-relocations at all, so this case is not relevant right? Did I miss anything?

[MaskRay]

In D92633#2433108, @tmsriram wrote:

You said : "The name -mpie-copy-relocations is misleading [1] and does not capture the idea that this option can actually apply to all of -fno-pic,-fpie, ..."

Could you please clarify why this option needs to apply to -fno-pic? Here is what I tried with trunk clang:

If the user wants to guarantee no copy relocations in -fno-pic code, they can theoretically apply -fno-direct-access-external-data to use a GOT indirection.
This is not implemented, though.

extern int var;
int get() { return var; }

$ clang -S foo.c -o -
....
movl var, %eax
popq %rbp
...

With -fno-pic, this will never need to use -mpie-copy-relocations at all, so this case is not relevant right? Did I miss anything?

-fno-pic code can only be used with -no-pie links (position-dependent executables) If var is not defined in the linked executable, it will have a copy relocation.

[tmsriram]

In D92633#2433979, @MaskRay wrote:

In D92633#2433108, @tmsriram wrote:

You said : "The name -mpie-copy-relocations is misleading [1] and does not capture the idea that this option can actually apply to all of -fno-pic,-fpie, ..."

Could you please clarify why this option needs to apply to -fno-pic? Here is what I tried with trunk clang:

If the user wants to guarantee no copy relocations in -fno-pic code, they can theoretically apply -fno-direct-access-external-data to use a GOT indirection.
This is not implemented, though.

extern int var;
int get() { return var; }

$ clang -S foo.c -o -
....
movl var, %eax
popq %rbp
...

With -fno-pic, this will never need to use -mpie-copy-relocations at all, so this case is not relevant right? Did I miss anything?

-fno-pic code can only be used with -no-pie links (position-dependent executables) If var is not defined in the linked executable, it will have a copy relocation.

Thanks for explaining. I know that by default (i.e. no-pic and no-pie), copy relocations will be used for external data accesses. So, you are saying that you are adding a mechanism to disable copy relocations for the no-pic/no-pie case too. Is there a need for this, purely a question. I know that copy relocations are frowned upon so maybe there was a feature request. If so, citing that would make it more clear. Thanks.

[MaskRay]

In D92633#2433999, @tmsriram wrote:

In D92633#2433979, @MaskRay wrote:

In D92633#2433108, @tmsriram wrote:

You said : "The name -mpie-copy-relocations is misleading [1] and does not capture the idea that this option can actually apply to all of -fno-pic,-fpie, ..."

Could you please clarify why this option needs to apply to -fno-pic? Here is what I tried with trunk clang:

If the user wants to guarantee no copy relocations in -fno-pic code, they can theoretically apply -fno-direct-access-external-data to use a GOT indirection.
This is not implemented, though.

extern int var;
int get() { return var; }

$ clang -S foo.c -o -
....
movl var, %eax
popq %rbp
...

With -fno-pic, this will never need to use -mpie-copy-relocations at all, so this case is not relevant right? Did I miss anything?

-fno-pic code can only be used with -no-pie links (position-dependent executables) If var is not defined in the linked executable, it will have a copy relocation.

Thanks for explaining. I know that by default (i.e. no-pic and no-pie), copy relocations will be used for external data accesses. So, you are saying that you are adding a mechanism to disable copy relocations for the no-pic/no-pie case too. Is there a need for this, purely a question. I know that copy relocations are frowned upon so maybe there was a feature request. If so, citing that would make it more clear. Thanks.

I don't know of a feature request.

Is there a need for this, purely a question.

A weak need: more to make the behavior more align with the option name and perhaps align with potential GCC behavior (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98112 if they decide to implement this).
It can also be argued that this can be used to remove a special case for ppc64 ELFv2, which essentially defaults to -fno-direct-access-external-data for -fno-pic (they prefer to not have copy relocations)

Supporting -fno-direct-access-external-data for -fno-pic is not difficult: a one/two line change to TargetMachine::shouldAssumeDSOLocal refining if (!(GV && GV->isThreadLocal()) && RM == Reloc::Static).

[tmsriram]

LGTM. I checked it completely and the patch makes total sense to me.

clang/include/clang/Driver/Options.td

1866

Would -fdirect-access-external-global be a more appropriate name?, data sounds generic to me but I don't have a strong opinion.

[MaskRay]

In D92633#2434166, @tmsriram wrote:

LGTM. I checked it completely and the patch makes total sense to me.

Thanks! The name bothers me a bit. There are two parts "direct-access" (direct access relocations like absolute relocations and PC-relative relocations) "external-data" (this is for an external global data symbol with default visibility) (-fno-plt is a similar option for function symbols)

"external global data symbol with default visibility" is apparently too long and not suitable for an option name.
I do not know how to fit default into the name, so I just omit it.
I think external implies global (undefined local symbols are not allowed, either by the assembler or by the linker in various binary formats), so external-global probably does not convey more information than external-data. In the end I still think -fdirect-access-external-data is the best name I can think of...

[tmsriram]

Sorry just one more thing which is a bit concerning:

When I do :

$ clang -fPIC -frxternal-data-access foo.c

You will omit the GOT but this object can go into a shared object and break the build as this does not apply to shared objects? Should we allow this at all for -fPIC? I dont see a need for this but if you want to, maybe warn? The user should know that this cannot go into a shared object right?
I am also ok with commenting that this option can do bad things for -fPIC and the user should know what they are doing.

[tmsriram]

In D92633#2434212, @MaskRay wrote:

In D92633#2434166, @tmsriram wrote:

LGTM. I checked it completely and the patch makes total sense to me.

Thanks! The name bothers me a bit. There are two parts "direct-access" (direct access relocations like absolute relocations and PC-relative relocations) "external-data" (this is for an external global data symbol with default visibility) (-fno-plt is a similar option for function symbols)

"external global data symbol with default visibility" is apparently too long and not suitable for an option name.
I do not know how to fit default into the name, so I just omit it.
I think external implies global (undefined local symbols are not allowed, either by the assembler or by the linker in various binary formats), so external-global probably does not convey more information than external-data. In the end I still think -fdirect-access-external-data is the best name I can think of...

Acknowledged. To me, global is more specific but I do not want to push this any further. Feel free to keep the current choice :)

[MaskRay]

In D92633#2434231, @tmsriram wrote:

Sorry just one more thing which is a bit concerning:

When I do :

$ clang -fPIC -frxternal-data-access foo.c

You will omit the GOT but this object can go into a shared object and break the build as this does not apply to shared objects? Should we allow this at all for -fPIC? I dont see a need for this but if you want to, maybe warn? The user should know that this cannot go into a shared object right?
I am also ok with commenting that this option can do bad things for -fPIC and the user should know what they are doing.

clang -fPIC -fdirect-access-eternal-data -c a.c; ld -no-pie a.o; ld -pie a.o (producing an executable with either -no-pie or -pie) is fine.

For -shared, because an ELF linker assumes interposition for non-local STV_DEFAULT symbols by default, linking such an object files requires some mechanism to make it non-preemptible.
The simplest is clang -fPIC -fdirect-access-external-data -c a.c; ld -shared -Bsymbolic a.o
Other mechanisms include: --dynamic-list (don't list the symbol) and --version-script (localize the symbol).
This is going to be tricky and I don't know how to fit the information into the few-line description of the option.

I just checked how to make -fdirect-access-eternal-data work for -fno-pic (both TargetMachine::shouldAssumeDSOLocal and CodeGenModule.cpp:shouldAssumeDSOLocal should not assume false for Reloc::Static), unfortunately there are 200 tests needing updates. (This reminds me that LLVM doesn't get the default for dso_local right, so many tests have dso_local in ELF/COFF but no dso_local in Mach-O. Unfortunately it is extremely difficult to fix it today (D76561))

[tmsriram]

In D92633#2434267, @MaskRay wrote:

In D92633#2434231, @tmsriram wrote:

Sorry just one more thing which is a bit concerning:

When I do :

$ clang -fPIC -frxternal-data-access foo.c

You will omit the GOT but this object can go into a shared object and break the build as this does not apply to shared objects? Should we allow this at all for -fPIC? I dont see a need for this but if you want to, maybe warn? The user should know that this cannot go into a shared object right?
I am also ok with commenting that this option can do bad things for -fPIC and the user should know what they are doing.

clang -fPIC -fdirect-access-eternal-data -c a.c; ld -no-pie a.o; ld -pie a.o (producing an executable with either -no-pie or -pie) is fine.

Yes, agreed. Putting this object into an executable (pie/no-pie) no matter how you compile it is always fine as long as the backend supports copy relocations. No issues there.

For -shared, because an ELF linker assumes interposition for non-local STV_DEFAULT symbols by default, linking such an object files requires some mechanism to make it non-preemptible.

Right, that was my point. Without -fPIC, we can be guaranteed that it won't go into a shared object and this case wouldn't arise.

The simplest is clang -fPIC -fdirect-access-external-data -c a.c; ld -shared -Bsymbolic a.o
Other mechanisms include: --dynamic-list (don't list the symbol) and --version-script (localize the symbol).
This is going to be tricky and I don't know how to fit the information into the few-line description of the option.

How about making this option applicable for -fpie/fPIE and the default case and *not allowing* it for -fPIC/-fpic? That seems the safest approach.

I just checked how to make -fdirect-access-eternal-data work for -fno-pic (both TargetMachine::shouldAssumeDSOLocal and CodeGenModule.cpp:shouldAssumeDSOLocal should not assume false for Reloc::Static), unfortunately there are 200 tests needing updates. (This reminds me that LLVM doesn't get the default for dso_local right, so many tests have dso_local in ELF/COFF but no dso_local in Mach-O. Unfortunately it is extremely difficult to fix it today (D76561))

Ok, I lost you here a bit. This should be fine for -fno-pic was my understanding.

Let me try to summarize the motivations of this patch:

1. Originally, the default build (fno-pie/fno-pic), always used direct access for external globals resulting in copy relocations if it is truly external at link time. You want to change that to be able to not have copy relocations with -fno-direct-access-external-data, and you claim this would be useful for POWER, great!
2. Originally, with -fPIE and -fpie, -mpie-copy-relocations allowed direct access to externals. This was always safe because the object was guaranteed to go into an executable. The new option preserves this behavior so there is no concern.
3. Originally, there was no way to generate direct accesses to external global variables with -fPIC/-fpic. That behavior will change if you support -fdirect-access-external-data with -fPIC. That is my concern that this adds to the complexity and the user should know what they are doing.

Given 3), I am wondering if you really need this patch. I will leave it to you but please do consider the fact that opening up this option to -fPIC might be a problem.

[MaskRay]

In D92633#2434337, @tmsriram wrote:

In D92633#2434267, @MaskRay wrote:

In D92633#2434231, @tmsriram wrote:

Sorry just one more thing which is a bit concerning:

When I do :

$ clang -fPIC -frxternal-data-access foo.c

You will omit the GOT but this object can go into a shared object and break the build as this does not apply to shared objects? Should we allow this at all for -fPIC? I dont see a need for this but if you want to, maybe warn? The user should know that this cannot go into a shared object right?
I am also ok with commenting that this option can do bad things for -fPIC and the user should know what they are doing.

clang -fPIC -fdirect-access-eternal-data -c a.c; ld -no-pie a.o; ld -pie a.o (producing an executable with either -no-pie or -pie) is fine.

Yes, agreed. Putting this object into an executable (pie/no-pie) no matter how you compile it is always fine as long as the backend supports copy relocations. No issues there.

For -shared, because an ELF linker assumes interposition for non-local STV_DEFAULT symbols by default, linking such an object files requires some mechanism to make it non-preemptible.

Right, that was my point. Without -fPIC, we can be guaranteed that it won't go into a shared object and this case wouldn't arise.

The simplest is clang -fPIC -fdirect-access-external-data -c a.c; ld -shared -Bsymbolic a.o
Other mechanisms include: --dynamic-list (don't list the symbol) and --version-script (localize the symbol).
This is going to be tricky and I don't know how to fit the information into the few-line description of the option.

How about making this option applicable for -fpie/fPIE and the default case and *not allowing* it for -fPIC/-fpic? That seems the safest approach.

I just checked how to make -fdirect-access-eternal-data work for -fno-pic (both TargetMachine::shouldAssumeDSOLocal and CodeGenModule.cpp:shouldAssumeDSOLocal should not assume false for Reloc::Static), unfortunately there are 200 tests needing updates. (This reminds me that LLVM doesn't get the default for dso_local right, so many tests have dso_local in ELF/COFF but no dso_local in Mach-O. Unfortunately it is extremely difficult to fix it today (D76561))

Ok, I lost you here a bit. This should be fine for -fno-pic was my understanding.

Let me try to summarize the motivations of this patch:

1. Originally, the default build (fno-pie/fno-pic), always used direct access for external globals resulting in copy relocations if it is truly external at link time. You want to change that to be able to not have copy relocations with -fno-direct-access-external-data, and you claim this would be useful for POWER, great!
2. Originally, with -fPIE and -fpie, -mpie-copy-relocations allowed direct access to externals. This was always safe because the object was guaranteed to go into an executable. The new option preserves this behavior so there is no concern.

Yes for 1 and 2. This patch only makes the options work for -fpie (as the original -mpie-copy-relocations does).

1 will be a nice cleanup (to drop 2 lines from TargetMachine::shouldAssumeDSOLocal) but it may require some test updates and it looks like CodeGen/MachineCSE.cpp exposes a crashing bug that it cannot handle non-dso_local external constant in -relocation-model=static mode correctly...

3. Originally, there was no way to generate direct accesses to external global variables with -fPIC/-fpic. That behavior will change if you support -fdirect-access-external-data with -fPIC. That is my concern that this adds to the complexity and the user should know what they are doing.

Given 3), I am wondering if you really need this patch. I will leave it to you but please do consider the fact that opening up this option to -fPIC might be a problem.

I agree. The behavior is not touched in this patch.
I think the existing -mpie-copy-relocations users should be aware that the option (-fdirect-access-external-data) should generally only be used with -fno-pic and -fpie.

[tmsriram]

In D92633#2434511, @MaskRay wrote:

In D92633#2434337, @tmsriram wrote:

In D92633#2434267, @MaskRay wrote:

In D92633#2434231, @tmsriram wrote:

Sorry just one more thing which is a bit concerning:

When I do :

$ clang -fPIC -frxternal-data-access foo.c

You will omit the GOT but this object can go into a shared object and break the build as this does not apply to shared objects? Should we allow this at all for -fPIC? I dont see a need for this but if you want to, maybe warn? The user should know that this cannot go into a shared object right?
I am also ok with commenting that this option can do bad things for -fPIC and the user should know what they are doing.

clang -fPIC -fdirect-access-eternal-data -c a.c; ld -no-pie a.o; ld -pie a.o (producing an executable with either -no-pie or -pie) is fine.

Yes, agreed. Putting this object into an executable (pie/no-pie) no matter how you compile it is always fine as long as the backend supports copy relocations. No issues there.

For -shared, because an ELF linker assumes interposition for non-local STV_DEFAULT symbols by default, linking such an object files requires some mechanism to make it non-preemptible.

Right, that was my point. Without -fPIC, we can be guaranteed that it won't go into a shared object and this case wouldn't arise.

The simplest is clang -fPIC -fdirect-access-external-data -c a.c; ld -shared -Bsymbolic a.o
Other mechanisms include: --dynamic-list (don't list the symbol) and --version-script (localize the symbol).
This is going to be tricky and I don't know how to fit the information into the few-line description of the option.

How about making this option applicable for -fpie/fPIE and the default case and *not allowing* it for -fPIC/-fpic? That seems the safest approach.

I just checked how to make -fdirect-access-eternal-data work for -fno-pic (both TargetMachine::shouldAssumeDSOLocal and CodeGenModule.cpp:shouldAssumeDSOLocal should not assume false for Reloc::Static), unfortunately there are 200 tests needing updates. (This reminds me that LLVM doesn't get the default for dso_local right, so many tests have dso_local in ELF/COFF but no dso_local in Mach-O. Unfortunately it is extremely difficult to fix it today (D76561))

Ok, I lost you here a bit. This should be fine for -fno-pic was my understanding.

Let me try to summarize the motivations of this patch:

1. Originally, the default build (fno-pie/fno-pic), always used direct access for external globals resulting in copy relocations if it is truly external at link time. You want to change that to be able to not have copy relocations with -fno-direct-access-external-data, and you claim this would be useful for POWER, great!
2. Originally, with -fPIE and -fpie, -mpie-copy-relocations allowed direct access to externals. This was always safe because the object was guaranteed to go into an executable. The new option preserves this behavior so there is no concern.

Yes for 1 and 2. This patch only makes the options work for -fpie (as the original -mpie-copy-relocations does).

1 will be a nice cleanup (to drop 2 lines from TargetMachine::shouldAssumeDSOLocal) but it may require some test updates and it looks like CodeGen/MachineCSE.cpp exposes a crashing bug that it cannot handle non-dso_local external constant in -relocation-model=static mode correctly...

3. Originally, there was no way to generate direct accesses to external global variables with -fPIC/-fpic. That behavior will change if you support -fdirect-access-external-data with -fPIC. That is my concern that this adds to the complexity and the user should know what they are doing.

Given 3), I am wondering if you really need this patch. I will leave it to you but please do consider the fact that opening up this option to -fPIC might be a problem.

I agree. The behavior is not touched in this patch.

Correct me if I am wrong, but I do see that this behavior is touched. Line 10 in -fdirect-access-external-data.c :

// RUN: %clang -### -c -target aarch64 %s -fpic -fdirect-access-external-data 2>&1 | FileCheck %s --check-prefix=DIRECT

With -fpic, the variable access will go directly and not via GOT.

I think the existing -mpie-copy-relocations users should be aware that the option (-fdirect-access-external-data) should generally only be used with -fno-pic and -fpie.

[MaskRay]

In D92633#2434714, @tmsriram wrote:

Correct me if I am wrong, but I do see that this behavior is touched. Line 10 in -fdirect-access-external-data.c :

// RUN: %clang -### -c -target aarch64 %s -fpic -fdirect-access-external-data 2>&1 | FileCheck %s --check-prefix=DIRECT

With -fpic, the variable access will go directly and not via GOT.

clang/test/Driver/fdirect-access-external-data.c is a driver test which tests how the driver passes options to CC1.

clang/lib/CodeGen/CodeGenModule.cpp says how the CC1 option affects the dso_local specifier in the LLVM IR output. Currently it is a no op for -fpic/-fPIC.

(I have made some tests. It looks like implementing -fno-direct-access-external-data for -fno-pic is not an insurmountable work: ~50 tests)

[tmsriram]

In D92633#2434766, @MaskRay wrote:

In D92633#2434714, @tmsriram wrote:

Correct me if I am wrong, but I do see that this behavior is touched. Line 10 in -fdirect-access-external-data.c :

// RUN: %clang -### -c -target aarch64 %s -fpic -fdirect-access-external-data 2>&1 | FileCheck %s --check-prefix=DIRECT

With -fpic, the variable access will go directly and not via GOT.

clang/test/Driver/fdirect-access-external-data.c is a driver test which tests how the driver passes options to CC1.

clang/lib/CodeGen/CodeGenModule.cpp says how the CC1 option affects the dso_local specifier in the LLVM IR output. Currently it is a no op for -fpic/-fPIC.

Great! Sorry I didnt realize this, this is fine with me now!

(I have made some tests. It looks like implementing -fno-direct-access-external-data for -fno-pic is not an insurmountable work: ~50 tests)

[MaskRay]

In D92633#2434768, @tmsriram wrote:

In D92633#2434766, @MaskRay wrote:

In D92633#2434714, @tmsriram wrote:

Correct me if I am wrong, but I do see that this behavior is touched. Line 10 in -fdirect-access-external-data.c :

// RUN: %clang -### -c -target aarch64 %s -fpic -fdirect-access-external-data 2>&1 | FileCheck %s --check-prefix=DIRECT

With -fpic, the variable access will go directly and not via GOT.

clang/test/Driver/fdirect-access-external-data.c is a driver test which tests how the driver passes options to CC1.

clang/lib/CodeGen/CodeGenModule.cpp says how the CC1 option affects the dso_local specifier in the LLVM IR output. Currently it is a no op for -fpic/-fPIC.

Great! Sorry I didnt realize this, this is fine with me now!

(I have made some tests. It looks like implementing -fno-direct-access-external-data for -fno-pic is not an insurmountable work: ~50 tests)

May I get a formal LGTM? 😋 I am happy to give GCC devs a few more days... https://gcc.gnu.org/pipermail/gcc/2021-January/234639.html (the previous feature request and gcc/ mailing list message has given them one month and -f[no-]direct-access-external-data is still the best name so far)

[tmsriram]

In D92633#2485811, @MaskRay wrote:

In D92633#2434768, @tmsriram wrote:

In D92633#2434766, @MaskRay wrote:

In D92633#2434714, @tmsriram wrote:

Correct me if I am wrong, but I do see that this behavior is touched. Line 10 in -fdirect-access-external-data.c :

// RUN: %clang -### -c -target aarch64 %s -fpic -fdirect-access-external-data 2>&1 | FileCheck %s --check-prefix=DIRECT

With -fpic, the variable access will go directly and not via GOT.

clang/test/Driver/fdirect-access-external-data.c is a driver test which tests how the driver passes options to CC1.

clang/lib/CodeGen/CodeGenModule.cpp says how the CC1 option affects the dso_local specifier in the LLVM IR output. Currently it is a no op for -fpic/-fPIC.

Great! Sorry I didnt realize this, this is fine with me now!

(I have made some tests. It looks like implementing -fno-direct-access-external-data for -fno-pic is not an insurmountable work: ~50 tests)

May I get a formal LGTM? 😋 I am happy to give GCC devs a few more days... https://gcc.gnu.org/pipermail/gcc/2021-January/234639.html (the previous feature request and gcc/ mailing list message has given them one month and -f[no-]direct-access-external-data is still the best name so far)

Ok, I can approve this.

clang/include/clang/Basic/CodeGenOptions.def

 
 /// Number of path components to strip when emitting checks. (0 == full
 /// filename)
 VALUE_CODEGENOPT(EmitCheckPathComponentsToStrip, 32, 0)
 
 /// Whether to report the hotness of the code region for optimization remarks.
 CODEGENOPT(DiagnosticsWithHotness, 1, 0)
 
-/// Whether copy relocations support is available when building as PIE.
-CODEGENOPT(PIECopyRelocations, 1, 0)
+/// Whether to use direct access relocations (instead of GOT) to reference external data symbols.
+CODEGENOPT(DirectAccessExternalData, 1, 0)
 
 /// Whether we should use the undefined behaviour optimization for control flow
 /// paths that reach the end of a function without executing a required return.
 CODEGENOPT(StrictReturn, 1, 1)
 
 /// Whether emit extra debug info for sample pgo profile collection.
 CODEGENOPT(DebugInfoForProfiling, 1, 0)
 

clang/include/clang/Driver/Options.td

def fpatchable_function_entry_EQ : Joined<["-"], "fpatchable-function-entry=">, Group<f_Group>, Flags<[CC1Option]>,
   MetaVarName<"<N,M>">, HelpText<"Generate M NOPs before function entry and N-M NOPs after function entry">;
 def fpcc_struct_return : Flag<["-"], "fpcc-struct-return">, Group<f_Group>, Flags<[CC1Option]>,
   HelpText<"Override the default ABI to return all structs on the stack">;
 def fpch_preprocess : Flag<["-"], "fpch-preprocess">, Group<f_Group>;
 def fpic : Flag<["-"], "fpic">, Group<f_Group>;
 def fno_pic : Flag<["-"], "fno-pic">, Group<f_Group>;
 def fpie : Flag<["-"], "fpie">, Group<f_Group>;
 def fno_pie : Flag<["-"], "fno-pie">, Group<f_Group>;
+def fdirect_access_external_data : Flag<["-"], "fdirect-access-external-data">, Group<f_Group>, Flags<[CC1Option]>,
+  HelpText<"Don't use GOT indirection to reference external data symbols">;
+def fno_direct_access_external_data : Flag<["-"], "fno-direct-access-external-data">, Group<f_Group>, Flags<[CC1Option]>,
+  HelpText<"Use GOT indirection to reference external data symbols">;
 defm plt : OptOutFFlag<"plt", "",
   "Use GOT indirection instead of PLT to make external function calls (x86 only)">;
 defm ropi : OptInFFlag<"ropi", "Generate read-only position independent code (ARM only)">;
 defm rwpi : OptInFFlag<"rwpi", "Generate read-write position independent code (ARM only)">;
 def fplugin_EQ : Joined<["-"], "fplugin=">, Group<f_Group>, Flags<[NoXarchOption]>, MetaVarName<"<dsopath>">,
   HelpText<"Load the named plugin (dynamic shared object)">;
 def fpass_plugin_EQ : Joined<["-"], "fpass-plugin=">,
   Group<f_Group>, Flags<[CC1Option]>, MetaVarName<"<dsopath>">,

 def mprefer_vector_width_EQ : Joined<["-"], "mprefer-vector-width=">, Group<m_Group>, Flags<[CC1Option]>,
   HelpText<"Specifies preferred vector width for auto-vectorization. Defaults to 'none' which allows target specific decisions.">;
 def mstack_protector_guard_EQ : Joined<["-"], "mstack-protector-guard=">, Group<m_Group>, Flags<[CC1Option]>,
   HelpText<"Use the given guard (global, tls) for addressing the stack-protector guard">;
 def mstack_protector_guard_offset_EQ : Joined<["-"], "mstack-protector-guard-offset=">, Group<m_Group>, Flags<[CC1Option]>,
   HelpText<"Use the given offset for addressing the stack-protector guard">;
 def mstack_protector_guard_reg_EQ : Joined<["-"], "mstack-protector-guard-reg=">, Group<m_Group>, Flags<[CC1Option]>,
   HelpText<"Use the given reg for addressing the stack-protector guard">;
-def mpie_copy_relocations : Flag<["-"], "mpie-copy-relocations">, Group<m_Group>,
-  Flags<[CC1Option]>,
-  HelpText<"Use copy relocations support for PIE builds">;
-def mno_pie_copy_relocations : Flag<["-"], "mno-pie-copy-relocations">, Group<m_Group>;
+def mpie_copy_relocations : Flag<["-"], "mpie-copy-relocations">,
+  Alias<fdirect_access_external_data>, Group<m_Group>;
+def mno_pie_copy_relocations : Flag<["-"], "mno-pie-copy-relocations">,
+  Alias<fno_direct_access_external_data>, Group<m_Group>;
 def mfentry : Flag<["-"], "mfentry">, HelpText<"Insert calls to fentry at function entry (x86/SystemZ only)">,
   Flags<[CC1Option]>, Group<m_Group>;
 def mnop_mcount : Flag<["-"], "mnop-mcount">, HelpText<"Generate mcount/__fentry__ calls as nops. To activate they need to be patched in.">,
   Flags<[CC1Option]>, Group<m_Group>;
 def mrecord_mcount : Flag<["-"], "mrecord-mcount">, HelpText<"Generate a __mcount_loc section entry for each __fentry__ call.">,
   Flags<[CC1Option]>, Group<m_Group>;
 def mpacked_stack : Flag<["-"], "mpacked-stack">, HelpText<"Use packed stack layout (SystemZ only).">,
   Flags<[CC1Option]>, Group<m_Group>;

clang/lib/CodeGen/CodeGenModule.cpp

static bool shouldAssumeDSOLocal(const CodeGenModule &CGM,
   llvm::Triple::ArchType Arch = TT.getArch();
   if (Arch == llvm::Triple::ppc || Arch == llvm::Triple::ppc64 ||
       Arch == llvm::Triple::ppc64le)
     return false;
 
   // If we can use copy relocations we can assume it is local.
   if (auto *Var = dyn_cast<llvm::GlobalVariable>(GV))
     if (!Var->isThreadLocal() &&
-        (RM == llvm::Reloc::Static || CGOpts.PIECopyRelocations))
+        (RM == llvm::Reloc::Static || CGOpts.DirectAccessExternalData))
       return true;
 
   // If we can use a plt entry as the symbol address we can assume it
   // is local.
   // FIXME: This should work for PIE, but the gold linker doesn't support it.
   if (isa<llvm::Function>(GV) && !CGOpts.NoPLT && RM == llvm::Reloc::Static)
     return true;
 

clang/lib/Driver/ToolChains/Clang.cpp

#endif
   if (KernelOrKext && RawTriple.isOSDarwin())
     CmdArgs.push_back("-fforbid-guard-variables");
 
   if (Args.hasFlag(options::OPT_mms_bitfields, options::OPT_mno_ms_bitfields,
                    Triple.isWindowsGNUEnvironment())) {
     CmdArgs.push_back("-mms-bitfields");
   }
 
-  if (Args.hasFlag(options::OPT_mpie_copy_relocations,
-                   options::OPT_mno_pie_copy_relocations,
-                   false)) {
-    CmdArgs.push_back("-mpie-copy-relocations");
-  }
+  // Non-PIC code defaults to -fdirect-access-external-data while PIC code
+  // defaults to -fno-direct-access-external-data. Pass the option if different
+  // from the default.
+  if (Arg *A = Args.getLastArg(options::OPT_fdirect_access_external_data,
+                               options::OPT_fno_direct_access_external_data))
+    if (A->getOption().matches(options::OPT_fdirect_access_external_data) !=
+        (PICLevel == 0))
+      A->render(Args, CmdArgs);
 
   if (Args.hasFlag(options::OPT_fno_plt, options::OPT_fplt, false)) {
     CmdArgs.push_back("-fno-plt");
   }
 
   // -fhosted is default.
   // TODO: Audit uses of KernelOrKext and see where it'd be more appropriate to
   // use Freestanding.

clang/lib/Frontend/CompilerInvocation.cpp

static bool ParseCodeGenArgs(CodeGenOptions &Opts, ArgList &Args, InputKind IK,
   Opts.SmallDataLimit =
       getLastArgIntValue(Args, OPT_msmall_data_limit, 0, Diags);
   Opts.FatalWarnings = Args.hasArg(OPT_massembler_fatal_warnings);
   Opts.NoWarn = Args.hasArg(OPT_massembler_no_warn);
   Opts.EnableSegmentedStacks = Args.hasArg(OPT_split_stacks);
   Opts.RelaxAll = Args.hasArg(OPT_mrelax_all);
   Opts.IncrementalLinkerCompatible =
       Args.hasArg(OPT_mincremental_linker_compatible);
-  Opts.PIECopyRelocations =
-      Args.hasArg(OPT_mpie_copy_relocations);
+  Opts.DirectAccessExternalData =
+      Args.hasArg(OPT_fdirect_access_external_data) ||
+      (!Args.hasArg(OPT_fno_direct_access_external_data) &&
+       getLastArgIntValue(Args, OPT_pic_level, 0, Diags) == 0);
   Opts.NoPLT = Args.hasArg(OPT_fno_plt);
   Opts.SaveTempLabels = Args.hasArg(OPT_msave_temp_labels);
   Opts.NoDwarfDirectoryAsm = Args.hasArg(OPT_fno_dwarf_directory_asm);
   Opts.SoftFloat = Args.hasArg(OPT_msoft_float);
   Opts.StrictEnums = Args.hasArg(OPT_fstrict_enums);
   Opts.StrictReturn = !Args.hasArg(OPT_fno_strict_return);
   Opts.StrictVTablePointers = Args.hasArg(OPT_fstrict_vtable_pointers);
   Opts.ForceEmitVTables = Args.hasArg(OPT_fforce_emit_vtables);

clang/test/CodeGen/dso-local-executable.c

 // PIE-NEXT: @weak_bar = extern_weak global i32
 // PIE-NEXT: @bar = external global i32
 // PIE-NEXT: @local_thread_var = dso_local thread_local global i32 42
 // PIE-NEXT: @thread_var = external thread_local global i32
 // PIE-DAG: declare void @foo()
 // PIE-DAG: define dso_local i32* @zed()
 // PIE-DAG: declare void @import_func()
 
-// RUN: %clang_cc1 -triple x86_64 -emit-llvm -pic-level 1 -pic-is-pie -mpie-copy-relocations %s -o - | FileCheck --check-prefix=PIE-DIRECT %s
+// RUN: %clang_cc1 -triple x86_64 -emit-llvm -pic-level 1 -pic-is-pie -fdirect-access-external-data %s -o - | FileCheck --check-prefix=PIE-DIRECT %s
 // PIE-DIRECT:      @baz = dso_local global i32 42
 // PIE-DIRECT-NEXT: @import_var = external dso_local global i32
 // PIE-DIRECT-NEXT: @weak_bar = extern_weak global i32
 // PIE-DIRECT-NEXT: @bar = external dso_local global i32
 // PIE-DIRECT-NEXT: @local_thread_var = dso_local thread_local global i32 42
 // PIE-DIRECT-NEXT: @thread_var = external thread_local global i32
 // PIE-DIRECT-DAG: declare void @foo()
 // PIE-DIRECT-DAG: define dso_local i32* @zed()
 // PIE-DIRECT-DAG: declare void @import_func()
 
 // RUN: %clang_cc1 -triple x86_64 -emit-llvm -mrelocation-model static -fno-plt %s -o - | FileCheck --check-prefix=NOPLT %s
 // NOPLT:      @baz = dso_local global i32 42
 // NOPLT-NEXT: @import_var = external dso_local global i32
 // NOPLT-NEXT: @weak_bar = extern_weak dso_local global i32
 // NOPLT-NEXT: @bar = external dso_local global i32
 // NOPLT-NEXT: @local_thread_var = dso_local thread_local global i32 42
 // NOPLT-NEXT: @thread_var = external thread_local global i32
 // NOPLT-DAG: declare void @foo()
 // NOPLT-DAG: define dso_local i32* @zed()
 // NOPLT-DAG: declare void @import_func()
 
-// RUN: %clang_cc1 -triple x86_64 -emit-llvm -fno-plt -pic-level 1 -pic-is-pie -mpie-copy-relocations %s -o - | FileCheck --check-prefix=PIE-DIRECT-NOPLT %s
+// RUN: %clang_cc1 -triple x86_64 -emit-llvm -fno-plt -pic-level 1 -pic-is-pie -fdirect-access-external-data %s -o - | FileCheck --check-prefix=PIE-DIRECT-NOPLT %s
 // PIE-DIRECT-NOPLT:      @baz = dso_local global i32 42
 // PIE-DIRECT-NOPLT-NEXT: @import_var = external dso_local global i32
 // PIE-DIRECT-NOPLT-NEXT: @weak_bar = extern_weak global i32
 // PIE-DIRECT-NOPLT-NEXT: @bar = external dso_local global i32
 // PIE-DIRECT-NOPLT-NEXT: @local_thread_var = dso_local thread_local global i32 42
 // PIE-DIRECT-NOPLT-NEXT: @thread_var = external thread_local global i32
 // PIE-DIRECT-NOPLT-DAG: declare void @foo()
 // PIE-DIRECT-NOPLT-DAG: define dso_local i32* @zed()
 // PIE-DIRECT-NOPLT-DAG: declare void @import_func()
 
-// RUN: %clang_cc1 -triple x86_64 -emit-llvm -pic-is-pie -fno-plt %s -o - | FileCheck --check-prefix=PIE-NO-PLT %s
+// RUN: %clang_cc1 -triple x86_64 -emit-llvm -pic-level 1 -pic-is-pie -fno-plt %s -o - | FileCheck --check-prefix=PIE-NO-PLT %s
 // RUN: %clang_cc1 -triple powerpc64le -emit-llvm -mrelocation-model static %s -o - | FileCheck --check-prefix=PIE-NO-PLT %s
 // PIE-NO-PLT:      @baz = dso_local global i32 42
 // PIE-NO-PLT-NEXT: @import_var = external global i32
 // PIE-NO-PLT-NEXT: @weak_bar = extern_weak global i32
 // PIE-NO-PLT-NEXT: @bar = external global i32
 // PIE-NO-PLT-NEXT: @local_thread_var = dso_local thread_local global i32 42
 // PIE-NO-PLT-NEXT: @thread_var = external thread_local global i32
 // PIE-NO-PLT-DAG:  declare void @import_func()

clang/test/Driver/fdirect-access-external-data.c

+/// -fno-pic code defaults to -fdirect-access-external-data.
+// RUN: %clang -### -c -target x86_64 %s 2>&1 | FileCheck %s --check-prefix=DEFAULT
+// RUN: %clang -### -c -target x86_64 %s -fdirect-access-external-data 2>&1 | FileCheck %s --check-prefix=DEFAULT
+// RUN: %clang -### -c -target x86_64 %s -fdirect-access-external-data -fno-direct-access-external-data 2>&1 | FileCheck %s --check-prefix=INDIRECT
+
+/// -fpie/-fpic code defaults to -fdirect-access-external-data.
+// RUN: %clang -### -c -target x86_64 %s -fpie 2>&1 | FileCheck %s --check-prefix=DEFAULT
+// RUN: %clang -### -c -target x86_64 %s -fpie -fno-direct-access-external-data -fdirect-access-external-data 2>&1 | FileCheck %s --check-prefix=DIRECT
+// RUN: %clang -### -c -target aarch64 %s -fpic 2>&1 | FileCheck %s --check-prefix=DEFAULT
+// RUN: %clang -### -c -target aarch64 %s -fpic -fdirect-access-external-data 2>&1 | FileCheck %s --check-prefix=DIRECT
+
+/// -m[no-]pie-copy-relocations are aliases for compatibility.
+// RUN: %clang -### -c -target riscv64 %s -mno-pie-copy-relocations 2>&1 | FileCheck %s --check-prefix=INDIRECT
+// RUN: %clang -### -c -target riscv64 %s -fpic -mpie-copy-relocations 2>&1 | FileCheck %s --check-prefix=DIRECT
+
+// DEFAULT-NOT: direct-access-external-data"
+// DIRECT:      "-fdirect-access-external-data"
+// INDIRECT:    "-fno-direct-access-external-data"