[clang] [llvm] [MC,clang,llvm-readobj,yaml2obj] Support CREL relocation format (PR #91280)
dwblaikie wrote: > This approahc parallels the strategy used for > [-enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang](https://reviews.llvm.org/D125142), > albeit a nicer name. Fair enough - yeah, if we're wordsmithing this. Maybe "allow" would be a good word, rather than "enable" (or no verb at all), as in `-allow-experimental-crel`? > While ELF allows extension space for processor/OS/application-specific > section types, using them introduces challenges since we want linker errors when SHT_CREL is unsupported (see isKnownSpecificSectionType in https://github.com/llvm/llvm-project/pull/85173): > > [SHT_LOUSER,SHT_HIUSER]: Not applicable as static relocation sections do not > have the SHF_ALLOC flag. I missed a step here - why is this range only applicable for SHF_ALLOC sections? Ah, from the patch you linked earlier, linkers don't fail on SHT_*USER range unless it's allocated... that seems a bit tenuous, though. Seems like this the range intended for this kind of experimentation, with the cost that it doesn't produce an error from existing linkers (though it could, but they're trying to be conservative/allow for extensions that don't need linker-awareness). Guess I'll leave that up to other folks to comment on. > [SHT_LOOS,SHT_HIOS]: Requires annoying SHF_OS_NONCONFORMING. We want psABI > documents to be willing to accept CREL when toolchain becomes ready, > especially if their relocatable files are huge due to linker relaxation (e.g. > RISC-V, LoongArch), we want to avoid GNUism / LLVMism. So in this case each OS would have to allocate their own number in in the SHT_*OS range? Yeah, that seems unfortunate. > [SHT_LOPROC,SHT_HIPROC]: Processor-specific and not applicable. Similar to the *OS case above, I guess. > We will unlikely change the format. I think we should start with the theory that the format will change - even if it doesn't, we wouldn't want to introduce this new thing and avoid change because we've made it hard to change if we discover in early testing that there's things we could do better. > Solaris-specific SHF_ORDERED and SHF_EXCLUDE, without a SunOS/Solaris name > infix/prefix/suffix, make them into glibc elf.h. > SHF_EXCLUDE gets picked due to its linker semantics but SHF_ORDERED is never > used. > A generic name SHT_CREL might not be fundamentally different from SHF_EXCLUDE. Got links to the history here, about how SHF_ORDERED/EXCLUDE came to be? https://github.com/llvm/llvm-project/pull/91280 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [MC,clang,llvm-readobj,yaml2obj] Support CREL relocation format (PR #91280)
smithp35 wrote: I will take a look, but may take me a while to go through it. Some very quick comments: * Would `--enable-experimental-crel` be a better name than `--experimental-crel` that makes it clear that the option is just an unlock of another flag, and not a flag in of itself? * I agree that the section type should be in the generic range. While it is in the experimental stage it could be possible to put it in SHT_LOOS SHT_HIOS range temporarily. When there is an official ELF code in the generic range it could be changed (forcing a recompile, or a migration script), or just have the LLVM tools implicitly convert from the old code to the new. For the experimental range. * While I can give a personal opinion. This will touch multiple components of LLVM each with their own code-owners. Will probably need a signal, either on the review or via discourse threads that the community is happy to go ahead with the addition of CREL. https://github.com/llvm/llvm-project/pull/91280 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [MC,clang,llvm-readobj,yaml2obj] Support CREL relocation format (PR #91280)
MaskRay wrote: Thanks for the comments. The syntax `-Wa,--crel -Wa,--experimental-crel` (or `-Wa,--crel,--experimental-crel`) might seem cumbersome, it serves a purpose: * `-Wa,--experimental-crel`: no effect * `-Wa,--crel`: driver error. Make sure users acknowledge the non-standard status. * `-Wa,--crel,--experimental-crel`: CREL As CREL adoption grows within the ecosystem, it has the potential to become a de-facto standard, similar to `SHF_EXCLUDE`. Once that happens, the `--experimental-crel` flag can be deprecated and eventually removed. This approahc parallels the strategy used for [`-enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang`](https://reviews.llvm.org/D125142), albeit a nicer name. --- I can split this PR into 5 components. * llvm-mc * clang driver * yaml2obj/obj2yaml * llvm-readobj * llvm-objdump The assembler testing might look bare-bone without llvm-readobj support. --- While ELF allows extension space for processor/OS/application-specific section types, using them introduces challenges since we want linker errors when SHT_CREL is unsupported (see `isKnownSpecificSectionType` in #85173): * [SHT_LOUSER,SHT_HIUSER]: Not applicable as static relocation sections do not have the SHF_ALLOC flag. * [SHT_LOOS,SHT_HIOS]: Requires annoying `SHF_OS_NONCONFORMING`. We want psABI documents to be willing to accept CREL when toolchain becomes ready, especially if their relocatable files are huge due to linker relaxation (e.g. RISC-V, LoongArch), we want to avoid GNUism / LLVMism. * [SHT_LOPROC,SHT_HIPROC]: Processor-specific and not applicable. We will unlikely change the format. I avoid the name `SHT_EXP_*` because the renaming would cause unnecessary churn. We also don't want to support two section type codes, because testing would be unnecessarily complex. Solaris-specific SHF_ORDERED and SHF_EXCLUDE, without a SunOS/Solaris name infix/prefix/suffix, make them into glibc elf.h. `SHF_EXCLUDE` gets picked due to its linker semantics but `SHF_ORDERED` is never used. A generic name `SHT_CREL` might not be fundamentally different from `SHF_ORDERED`. https://github.com/llvm/llvm-project/pull/91280 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [MC,clang,llvm-readobj,yaml2obj] Support CREL relocation format (PR #91280)
dwblaikie wrote: Oh, and I take it there's no /official/ extension space in the SHT_* space? The intent is to standardize it where it lies? (like use 20 for the shipped version? Or eventually get some lower designation?) I understand tnhe hesitance to use "SHT_LLVM" or the like (though equally, it does seem suitable (to try to use a name less likely to collide), if this is an experiment ,but I understand other projects may have some not-invented-here negative sentiment to such a thing), perhaps "SHT_EXP" wouldn't be too bad? https://github.com/llvm/llvm-project/pull/91280 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [MC,clang,llvm-readobj,yaml2obj] Support CREL relocation format (PR #91280)
dwblaikie wrote: Presumably this'll be split out into separate reviews for the components here? (I'd guess llvm-mc then clang integrated assembler, with readobj and yaml2obj in any order/don't have dependencies, unless they're needed for testing, in which case I guess they come first?) I hesitate to comment on the specifics while it's all together as I imagine it'll become hard to follow the different commentary across the larger patch/different project areas, etc. (though the flag design seems strange to me - having --crel and --experimental-crel, rather than having only the latter (and renaming it in the future, rather than using two flags now and removing one in the future)) https://github.com/llvm/llvm-project/pull/91280 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [MC,clang,llvm-readobj,yaml2obj] Support CREL relocation format (PR #91280)
llvmbot wrote:
@llvm/pr-subscribers-clang-driver
@llvm/pr-subscribers-clang
Author: Fangrui Song (MaskRay)
Changes
CREL is a compact relocation format for the ELF object file format.
This patch adds integrated assembler support (using the RELA form),
which can be enabled with `clang -c -Wa,--crel,--experimental-crel`.
`-Wa,--experimental-crel` indicates that CREL is experimental and not
a standard. `-Wa,--experimental-crel` might be removed in the future.
* We take a section type code 20 from the generic range for `SHT_CREL`.
We avoided using `SHT_LLVM_` or `SHT_GNU_` to maintain broader
applicability for interested psABIs.
* In the extremely unlikely case the generic ABI assigns 20 to another
purpose, and existing toolchains generate relocatable files using that
code (unlikely if we ensure GNU and LLVM don't do this), any conflicts
would be the user's responsibility to resolve.
This patch also adds llvm-readobj support (for both REL and RELA forms)
to facilitate testing the assembler. Additionally, yaml2obj gains
support for the RELA form to aid testing with llvm-readobj.
Currently, linking the generated relocatable file with GNU ld will fail
because GNU ld doesn't support CREL yet.
unknown architecture of input file `a.o' is incompatible with i386:x86-64
output
lld will also produce an error when attempting to link a CREL relocatable file.
The support will come in a future change.
Link:
https://discourse.llvm.org/t/rfc-crel-a-compact-relocation-format-for-elf/77600
---
Patch is 72.41 KiB, truncated to 20.00 KiB below, full version:
https://github.com/llvm/llvm-project/pull/91280.diff
32 Files Affected:
- (modified) clang/include/clang/Basic/CodeGenOptions.def (+1)
- (modified) clang/include/clang/Basic/DiagnosticDriverKinds.td (+3)
- (modified) clang/include/clang/Driver/Options.td (+3)
- (modified) clang/lib/CodeGen/BackendUtil.cpp (+1)
- (modified) clang/lib/Driver/ToolChains/Clang.cpp (+18)
- (modified) clang/lib/Driver/ToolChains/CommonArgs.cpp (+21)
- (added) clang/test/Driver/crel.c (+24)
- (added) clang/test/Misc/cc1as-crel.s (+6)
- (modified) clang/tools/driver/cc1as_main.cpp (+6)
- (modified) llvm/include/llvm/BinaryFormat/DynamicTags.def (+2)
- (modified) llvm/include/llvm/BinaryFormat/ELF.h (+1)
- (modified) llvm/include/llvm/MC/MCTargetOptions.h (+3)
- (modified) llvm/include/llvm/MC/MCTargetOptionsCommandFlags.h (+1)
- (modified) llvm/include/llvm/Object/ELF.h (+5)
- (modified) llvm/include/llvm/Object/ELFObjectFile.h (+64-6)
- (modified) llvm/include/llvm/Object/ELFTypes.h (+25)
- (modified) llvm/lib/MC/ELFObjectWriter.cpp (+84-26)
- (modified) llvm/lib/MC/MCTargetOptionsCommandFlags.cpp (+6)
- (modified) llvm/lib/Object/ELF.cpp (+63)
- (modified) llvm/lib/ObjectYAML/ELFEmitter.cpp (+53-7)
- (modified) llvm/lib/ObjectYAML/ELFYAML.cpp (+2)
- (added) llvm/test/MC/ELF/crel-32.s (+16)
- (added) llvm/test/MC/ELF/crel.s (+100)
- (added) llvm/test/tools/llvm-readobj/ELF/crel.test (+180)
- (modified) llvm/test/tools/llvm-readobj/ELF/dynamic-reloc.test (+25-6)
- (modified) llvm/test/tools/llvm-readobj/ELF/relocation-errors.test (+18-1)
- (modified) llvm/test/tools/yaml2obj/ELF/dynamic-relocations.yaml (+4-1)
- (modified) llvm/test/tools/yaml2obj/ELF/reloc-sec-entry-size.yaml (+5)
- (added) llvm/test/tools/yaml2obj/ELF/relocation-crel.yaml (+63)
- (modified) llvm/test/tools/yaml2obj/ELF/relocation-missing-symbol.yaml (+2-1)
- (modified) llvm/test/tools/yaml2obj/ELF/relocation-type.yaml (+3-1)
- (modified) llvm/tools/llvm-readobj/ELFDumper.cpp (+75-6)
``diff
diff --git a/clang/include/clang/Basic/CodeGenOptions.def
b/clang/include/clang/Basic/CodeGenOptions.def
index 340b08dd7e2a33..3229f77eef1fcc 100644
--- a/clang/include/clang/Basic/CodeGenOptions.def
+++ b/clang/include/clang/Basic/CodeGenOptions.def
@@ -36,6 +36,7 @@ VALUE_CODEGENOPT(Name, Bits, Default)
#endif
CODEGENOPT(DisableIntegratedAS, 1, 0) ///< -no-integrated-as
+CODEGENOPT(Crel, 1, 0) ///< -Wa,--crel
CODEGENOPT(RelaxELFRelocations, 1, 1) ///< -Wa,-mrelax-relocations={yes,no}
CODEGENOPT(AsmVerbose, 1, 0) ///< -dA, -fverbose-asm.
CODEGENOPT(PreserveAsmComments, 1, 1) ///< -dA, -fno-preserve-as-comments.
diff --git a/clang/include/clang/Basic/DiagnosticDriverKinds.td
b/clang/include/clang/Basic/DiagnosticDriverKinds.td
index 9781fcaa4ff5e9..e9cea8967c1334 100644
--- a/clang/include/clang/Basic/DiagnosticDriverKinds.td
+++ b/clang/include/clang/Basic/DiagnosticDriverKinds.td
@@ -809,6 +809,9 @@ def warn_drv_missing_multilib : Warning<
def note_drv_available_multilibs : Note<
"available multilibs are:%0">;
+def err_drv_experimental_crel : Error<
+ "-Wa,--experimental-crel must be specified to use -Wa,--crel. CREL is
experimental and takes a non-standard section type code">;
+
def warn_android_unversioned_fallback : Warning<
"Using unversioned Android target directory %0 for target %1. Unversioned"
" directories will not be used
[clang] [llvm] [MC,clang,llvm-readobj,yaml2obj] Support CREL relocation format (PR #91280)
llvmbot wrote:
@llvm/pr-subscribers-mc
Author: Fangrui Song (MaskRay)
Changes
CREL is a compact relocation format for the ELF object file format.
This patch adds integrated assembler support (using the RELA form),
which can be enabled with `clang -c -Wa,--crel,--experimental-crel`.
`-Wa,--experimental-crel` indicates that CREL is experimental and not
a standard. `-Wa,--experimental-crel` might be removed in the future.
* We take a section type code 20 from the generic range for `SHT_CREL`.
We avoided using `SHT_LLVM_` or `SHT_GNU_` to maintain broader
applicability for interested psABIs.
* In the extremely unlikely case the generic ABI assigns 20 to another
purpose, and existing toolchains generate relocatable files using that
code (unlikely if we ensure GNU and LLVM don't do this), any conflicts
would be the user's responsibility to resolve.
This patch also adds llvm-readobj support (for both REL and RELA forms)
to facilitate testing the assembler. Additionally, yaml2obj gains
support for the RELA form to aid testing with llvm-readobj.
Currently, linking the generated relocatable file with GNU ld will fail
because GNU ld doesn't support CREL yet.
unknown architecture of input file `a.o' is incompatible with i386:x86-64
output
lld will also produce an error when attempting to link a CREL relocatable file.
The support will come in a future change.
Link:
https://discourse.llvm.org/t/rfc-crel-a-compact-relocation-format-for-elf/77600
---
Patch is 72.41 KiB, truncated to 20.00 KiB below, full version:
https://github.com/llvm/llvm-project/pull/91280.diff
32 Files Affected:
- (modified) clang/include/clang/Basic/CodeGenOptions.def (+1)
- (modified) clang/include/clang/Basic/DiagnosticDriverKinds.td (+3)
- (modified) clang/include/clang/Driver/Options.td (+3)
- (modified) clang/lib/CodeGen/BackendUtil.cpp (+1)
- (modified) clang/lib/Driver/ToolChains/Clang.cpp (+18)
- (modified) clang/lib/Driver/ToolChains/CommonArgs.cpp (+21)
- (added) clang/test/Driver/crel.c (+24)
- (added) clang/test/Misc/cc1as-crel.s (+6)
- (modified) clang/tools/driver/cc1as_main.cpp (+6)
- (modified) llvm/include/llvm/BinaryFormat/DynamicTags.def (+2)
- (modified) llvm/include/llvm/BinaryFormat/ELF.h (+1)
- (modified) llvm/include/llvm/MC/MCTargetOptions.h (+3)
- (modified) llvm/include/llvm/MC/MCTargetOptionsCommandFlags.h (+1)
- (modified) llvm/include/llvm/Object/ELF.h (+5)
- (modified) llvm/include/llvm/Object/ELFObjectFile.h (+64-6)
- (modified) llvm/include/llvm/Object/ELFTypes.h (+25)
- (modified) llvm/lib/MC/ELFObjectWriter.cpp (+84-26)
- (modified) llvm/lib/MC/MCTargetOptionsCommandFlags.cpp (+6)
- (modified) llvm/lib/Object/ELF.cpp (+63)
- (modified) llvm/lib/ObjectYAML/ELFEmitter.cpp (+53-7)
- (modified) llvm/lib/ObjectYAML/ELFYAML.cpp (+2)
- (added) llvm/test/MC/ELF/crel-32.s (+16)
- (added) llvm/test/MC/ELF/crel.s (+100)
- (added) llvm/test/tools/llvm-readobj/ELF/crel.test (+180)
- (modified) llvm/test/tools/llvm-readobj/ELF/dynamic-reloc.test (+25-6)
- (modified) llvm/test/tools/llvm-readobj/ELF/relocation-errors.test (+18-1)
- (modified) llvm/test/tools/yaml2obj/ELF/dynamic-relocations.yaml (+4-1)
- (modified) llvm/test/tools/yaml2obj/ELF/reloc-sec-entry-size.yaml (+5)
- (added) llvm/test/tools/yaml2obj/ELF/relocation-crel.yaml (+63)
- (modified) llvm/test/tools/yaml2obj/ELF/relocation-missing-symbol.yaml (+2-1)
- (modified) llvm/test/tools/yaml2obj/ELF/relocation-type.yaml (+3-1)
- (modified) llvm/tools/llvm-readobj/ELFDumper.cpp (+75-6)
``diff
diff --git a/clang/include/clang/Basic/CodeGenOptions.def
b/clang/include/clang/Basic/CodeGenOptions.def
index 340b08dd7e2a33..3229f77eef1fcc 100644
--- a/clang/include/clang/Basic/CodeGenOptions.def
+++ b/clang/include/clang/Basic/CodeGenOptions.def
@@ -36,6 +36,7 @@ VALUE_CODEGENOPT(Name, Bits, Default)
#endif
CODEGENOPT(DisableIntegratedAS, 1, 0) ///< -no-integrated-as
+CODEGENOPT(Crel, 1, 0) ///< -Wa,--crel
CODEGENOPT(RelaxELFRelocations, 1, 1) ///< -Wa,-mrelax-relocations={yes,no}
CODEGENOPT(AsmVerbose, 1, 0) ///< -dA, -fverbose-asm.
CODEGENOPT(PreserveAsmComments, 1, 1) ///< -dA, -fno-preserve-as-comments.
diff --git a/clang/include/clang/Basic/DiagnosticDriverKinds.td
b/clang/include/clang/Basic/DiagnosticDriverKinds.td
index 9781fcaa4ff5e9..e9cea8967c1334 100644
--- a/clang/include/clang/Basic/DiagnosticDriverKinds.td
+++ b/clang/include/clang/Basic/DiagnosticDriverKinds.td
@@ -809,6 +809,9 @@ def warn_drv_missing_multilib : Warning<
def note_drv_available_multilibs : Note<
"available multilibs are:%0">;
+def err_drv_experimental_crel : Error<
+ "-Wa,--experimental-crel must be specified to use -Wa,--crel. CREL is
experimental and takes a non-standard section type code">;
+
def warn_android_unversioned_fallback : Warning<
"Using unversioned Android target directory %0 for target %1. Unversioned"
" directories will not be used in Clang 19. Provide a versioned
[clang] [llvm] [MC,clang,llvm-readobj,yaml2obj] Support CREL relocation format (PR #91280)
https://github.com/MaskRay created
https://github.com/llvm/llvm-project/pull/91280
CREL is a compact relocation format for the ELF object file format.
This patch adds integrated assembler support (using the RELA form),
which can be enabled with `clang -c -Wa,--crel,--experimental-crel`.
`-Wa,--experimental-crel` indicates that CREL is experimental and not
a standard. `-Wa,--experimental-crel` might be removed in the future.
* We take a section type code 20 from the generic range for `SHT_CREL`.
We avoided using `SHT_LLVM_` or `SHT_GNU_` to maintain broader
applicability for interested psABIs.
* In the extremely unlikely case the generic ABI assigns 20 to another
purpose, and existing toolchains generate relocatable files using that
code (unlikely if we ensure GNU and LLVM don't do this), any conflicts
would be the user's responsibility to resolve.
This patch also adds llvm-readobj support (for both REL and RELA forms)
to facilitate testing the assembler. Additionally, yaml2obj gains
support for the RELA form to aid testing with llvm-readobj.
Currently, linking the generated relocatable file with GNU ld will fail
because GNU ld doesn't support CREL yet.
unknown architecture of input file `a.o' is incompatible with i386:x86-64
output
lld will also produce an error when attempting to link a CREL relocatable file.
The support will come in a future change.
Link:
https://discourse.llvm.org/t/rfc-crel-a-compact-relocation-format-for-elf/77600
>From a0cfafb82db825512b0ca44778fa9d4bb435563d Mon Sep 17 00:00:00 2001
From: Fangrui Song
Date: Mon, 6 May 2024 15:37:50 -0700
Subject: [PATCH] =?UTF-8?q?[=F0=9D=98=80=F0=9D=97=BD=F0=9D=97=BF]=20initia?=
=?UTF-8?q?l=20version?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Created using spr 1.3.5-bogner
---
clang/include/clang/Basic/CodeGenOptions.def | 1 +
.../clang/Basic/DiagnosticDriverKinds.td | 3 +
clang/include/clang/Driver/Options.td | 3 +
clang/lib/CodeGen/BackendUtil.cpp | 1 +
clang/lib/Driver/ToolChains/Clang.cpp | 18 ++
clang/lib/Driver/ToolChains/CommonArgs.cpp| 21 ++
clang/test/Driver/crel.c | 24 +++
clang/test/Misc/cc1as-crel.s | 6 +
clang/tools/driver/cc1as_main.cpp | 6 +
.../include/llvm/BinaryFormat/DynamicTags.def | 2 +
llvm/include/llvm/BinaryFormat/ELF.h | 1 +
llvm/include/llvm/MC/MCTargetOptions.h| 3 +
.../llvm/MC/MCTargetOptionsCommandFlags.h | 1 +
llvm/include/llvm/Object/ELF.h| 5 +
llvm/include/llvm/Object/ELFObjectFile.h | 70 ++-
llvm/include/llvm/Object/ELFTypes.h | 25 +++
llvm/lib/MC/ELFObjectWriter.cpp | 110 ---
llvm/lib/MC/MCTargetOptionsCommandFlags.cpp | 6 +
llvm/lib/Object/ELF.cpp | 63 ++
llvm/lib/ObjectYAML/ELFEmitter.cpp| 60 +-
llvm/lib/ObjectYAML/ELFYAML.cpp | 2 +
llvm/test/MC/ELF/crel-32.s| 16 ++
llvm/test/MC/ELF/crel.s | 100 ++
llvm/test/tools/llvm-readobj/ELF/crel.test| 180 ++
.../tools/llvm-readobj/ELF/dynamic-reloc.test | 31 ++-
.../llvm-readobj/ELF/relocation-errors.test | 19 +-
.../yaml2obj/ELF/dynamic-relocations.yaml | 5 +-
.../yaml2obj/ELF/reloc-sec-entry-size.yaml| 5 +
.../tools/yaml2obj/ELF/relocation-crel.yaml | 63 ++
.../ELF/relocation-missing-symbol.yaml| 3 +-
.../tools/yaml2obj/ELF/relocation-type.yaml | 4 +-
llvm/tools/llvm-readobj/ELFDumper.cpp | 81 +++-
32 files changed, 883 insertions(+), 55 deletions(-)
create mode 100644 clang/test/Driver/crel.c
create mode 100644 clang/test/Misc/cc1as-crel.s
create mode 100644 llvm/test/MC/ELF/crel-32.s
create mode 100644 llvm/test/MC/ELF/crel.s
create mode 100644 llvm/test/tools/llvm-readobj/ELF/crel.test
create mode 100644 llvm/test/tools/yaml2obj/ELF/relocation-crel.yaml
diff --git a/clang/include/clang/Basic/CodeGenOptions.def
b/clang/include/clang/Basic/CodeGenOptions.def
index 340b08dd7e2a33..3229f77eef1fcc 100644
--- a/clang/include/clang/Basic/CodeGenOptions.def
+++ b/clang/include/clang/Basic/CodeGenOptions.def
@@ -36,6 +36,7 @@ VALUE_CODEGENOPT(Name, Bits, Default)
#endif
CODEGENOPT(DisableIntegratedAS, 1, 0) ///< -no-integrated-as
+CODEGENOPT(Crel, 1, 0) ///< -Wa,--crel
CODEGENOPT(RelaxELFRelocations, 1, 1) ///< -Wa,-mrelax-relocations={yes,no}
CODEGENOPT(AsmVerbose, 1, 0) ///< -dA, -fverbose-asm.
CODEGENOPT(PreserveAsmComments, 1, 1) ///< -dA, -fno-preserve-as-comments.
diff --git a/clang/include/clang/Basic/DiagnosticDriverKinds.td
b/clang/include/clang/Basic/DiagnosticDriverKinds.td
index 9781fcaa4ff5e9..e9cea8967c1334 100644
--- a/clang/include/clang/Basic/DiagnosticDriverKinds.td
+++ b/clang/include/clang/Basic/DiagnosticDriverKinds.td
@@ -809,6 +809,9 @@ def
