[RISCV][RFC] Add Clang support for RISC-V overlay system

[edward-jones]

Summary

For a description of the riscv-overlay system proposal: https://github.com/riscv-software-src/riscv-overlay/

This is the Clang component of a change to add support for a proposed 'overlay' system for RISC-V to LLVM.

This adds two new attributes, attribute((overlaydata)), and attribute((overlaycall)), which are used to mark functions or global data as only accessible through the overlay engine. Internally they are converted to 'overlay-data' and 'overlay-call' attributes in LLVM IR.

This change also adds the option -fcomrv to enable use of the overlay system. This has the effect of reserving registers x28, x29, x30 and x31 for exclusive used by the overlay engine.

[jrtc27]

I don't see anything giving an error if you try and use the new badly-named option for an architecture other than RISC-V (beyond the usual unused argument warning that's only an error with -Werror)?

clang/include/clang/Basic/Attr.td

348

I thought the idea for this proposal was to come up with something that wasn't RISC-V specific (an architecture-independent specification and a RISC-V-specific supplement for how that is mapped to RISC-V) to get industry buy-in?

1793

If you want this to be portable to non-GNU compilers you should consider using a keyword instead (which can still map to an attribute internally). That also tends to get you better errors (there are places where type attributes can get silently ignored currently).

clang/include/clang/Basic/AttrDocs.td

2149

Why not just a single attribute that DTRT based on the type?

clang/include/clang/Driver/Options.td

3232

What on earth is this name?

clang/test/CodeGen/riscv-overlaycall.c

1 ↗

(On Diff #371111)

Use update_cc_test_checks.py

clang/test/Driver/riscv-comrv.c

3 ↗

(On Diff #371111)

Don't write a driver test that requires the backend, you don't need that to test this

clang/test/Sema/riscv-overlaycall-namespace.cpp

7 ↗

(On Diff #371111)

This error message is misleading. The semantics also don't seem great to me.

[MaskRay]

The name "overlay" is ambiguous. Even after I ruled out Gentoo Overlay and overlayfs, I am thinking whether this has anything to do with OVERLAY description in a linker script: https://sourceware.org/binutils/docs/ld/Overlay-Description.html#Overlay-Description

which are used to mark functions or global data as only accessible through the overlay engine

Can you give more descriptions for folks who don't follow the RISC-V side proposal but need to review your changes? :)

[jrtc27]

In D109372#2987405, @MaskRay wrote:

The name "overlay" is ambiguous. Even after I ruled out Gentoo Overlay and overlayfs, I am thinking whether this has anything to do with OVERLAY description in a linker script: https://sourceware.org/binutils/docs/ld/Overlay-Description.html#Overlay-Description

which are used to mark functions or global data as only accessible through the overlay engine

Can you give more descriptions for folks who don't follow the RISC-V side proposal but need to review your changes? :)

Basically hardware-assisted code+rodata banking (I guess either by actually banking ROMs or just paging stuff in and out) that's mostly transparent to software. Functions at the boundary of components (don't know what the granularity is) use a weird indirect calling convention where you instead call into some magic runtime with a unique ID for the callee, it ensures everything's loaded and then tail calls it for you.

[aaron.ballman]

clang/include/clang/Basic/Attr.td

1790–1792

This is not typical attribute behavior -- if the target architecture doesn't support the attribute, are the semantics such that an error is appropriate/required? Put another way, why do we want to trigger an error for this attribute while not triggering errors for other target-specific attributes (like calling conventions)?

1794

Does GCC support this attribute? If not, this should be using the Clang spelling (same below).

Also, overlaycall is pretty hard to read; why not overlay_call and overlay_data?

1795

What about Objective-C methods?

clang/include/clang/Basic/DiagnosticDriverKinds.td

36

clang/include/clang/Basic/DiagnosticSemaKinds.td

314

321

clang/lib/Driver/ToolChains/Arch/RISCV.cpp

496

clang/lib/Driver/ToolChains/Clang.cpp

2100

clang/lib/Frontend/CompilerInvocation.cpp

4066 ↗

(On Diff #371111)

4461 ↗

(On Diff #371111)

clang/lib/Sema/SemaDecl.cpp

3365

You should fix this formatting nit.

clang/lib/Sema/SemaDeclAttr.cpp

2043–2047

This shouldn't be necessary, the automated checking should handle it automatically.

2056–2058

Please use NoInlineAttr::CreateImplicit() instead.

8518–8523

Please write a handle function for this as with all the other attributes (we have hopes to someday do more tablegen in this area, so sticking with the same pattern in this switch is strongly preferred).

[edward-jones]

In D109372#2987411, @jrtc27 wrote:

In D109372#2987405, @MaskRay wrote:

The name "overlay" is ambiguous. Even after I ruled out Gentoo Overlay and overlayfs, I am thinking whether this has anything to do with OVERLAY description in a linker script: https://sourceware.org/binutils/docs/ld/Overlay-Description.html#Overlay-Description

which are used to mark functions or global data as only accessible through the overlay engine

Can you give more descriptions for folks who don't follow the RISC-V side proposal but need to review your changes? :)

Basically hardware-assisted code+rodata banking (I guess either by actually banking ROMs or just paging stuff in and out) that's mostly transparent to software. Functions at the boundary of components (don't know what the granularity is) use a weird indirect calling convention where you instead call into some magic runtime with a unique ID for the callee, it ensures everything's loaded and then tail calls it for you.

Yes it's essentially this. The start of the proposal for this 'overlay' system for RISC-V is a FOSDEM talk 'Cacheable Overlay Manager RISC‐V'. That's also the source of the weird name for the -fcomrv option name.

Would something like -foverlay-manager make more sense? (maybe an -m option would actually be more appropriate given this is still very RISC-V specific?). I'm not sure how to disambiguate from the many overloaded meanings of 'overlay'.

Thank's for the feedback. I'll update this and come back with a tidier patch.

clang/include/clang/Basic/Attr.td

1790–1792

If the attribute is being used then the expectation is that it is being supported by an overlay engine, and if that isn't the case then it implies an error in the build setup. That said I need to check this because I'm not convinced it's necessary.

1793

I don't think much consideration has been given to other compilers, but would it be unreasonable for the interface to this feature to not necessarily be identical between GNU and non-GNU compilers?

That said, I'm happy to switch to a keyword, especially if as you mention there are cases where an attribute can silently go missing without error. I'm not sure on the distinction of when to use a keyword vs attribute though, given that keywords are used pretty sparingly in comparison.

clang/include/clang/Basic/AttrDocs.td

2149

Good point. I'll see if I can do that. The fact we used multiple attributes is mainly a consequence of how we put this together rather than any inherent technical need I think.

clang/test/Sema/riscv-overlaycall-namespace.cpp

7 ↗

(On Diff #371111)

From recollection the current overlay system only works with externally visible symbols and these semantics are a consequence of that.

That said, it's not documented in the code, and as you point out the error message is just wrong so I'll fix this.

[aaron.ballman]

clang/include/clang/Basic/Attr.td

1790–1792

Thanks for looking into it! My preference is for the unknown attribute to be ignored (with diagnostic) on other targets unless there's a strong argument for why it's an error.

1793

This isn't a type attribute, so I don't think there's a risk of the attribute getting lost.

[jrtc27]

clang/include/clang/Basic/Attr.td

1793

This one isn't, but the data one is

[aaron.ballman]

clang/include/clang/Basic/Attr.td

1793

Oh, derp, thank you for catching that, somehow I completely missed it! I was thrown off by there being a lot of problems with it, but all the problems made it look like a declaration attribute.

Type attributes come with their own fun set of questions, like: does the attribute impact the type for overloading? SFINAE? Name mangling?

1802

This subject list is incorrect -- the subject is a VarDecl, but that's not a type.

clang/include/clang/Basic/AttrDocs.td

2153

This description is wrong if this is intended to be a type attribute. A global constant is not a type.

clang/lib/Sema/SemaDeclAttr.cpp

8518–8523

Oops, this is entirely wrong -- if this is a type attribute, it should be handled from processTypeAttrs() in SemaType.cpp.

[the_o]

In D109372#2989299, @edward-jones wrote:

In D109372#2987411, @jrtc27 wrote:

In D109372#2987405, @MaskRay wrote:

The name "overlay" is ambiguous. Even after I ruled out Gentoo Overlay and overlayfs, I am thinking whether this has anything to do with OVERLAY description in a linker script: https://sourceware.org/binutils/docs/ld/Overlay-Description.html#Overlay-Description

which are used to mark functions or global data as only accessible through the overlay engine

Can you give more descriptions for folks who don't follow the RISC-V side proposal but need to review your changes? :)

Basically hardware-assisted code+rodata banking (I guess either by actually banking ROMs or just paging stuff in and out) that's mostly transparent to software. Functions at the boundary of components (don't know what the granularity is) use a weird indirect calling convention where you instead call into some magic runtime with a unique ID for the callee, it ensures everything's loaded and then tail calls it for you.

Yes it's essentially this. The start of the proposal for this 'overlay' system for RISC-V is a FOSDEM talk 'Cacheable Overlay Manager RISC‐V'. That's also the source of the weird name for the -fcomrv option name.

Would something like -foverlay-manager make more sense? (maybe an -m option would actually be more appropriate given this is still very RISC-V specific?). I'm not sure how to disambiguate from the many overloaded meanings of 'overlay'.

Thank's for the feedback. I'll update this and come back with a tidier patch.

Adding my two cents:
More info about Overlay can be found on the Overlay standard at 'FOSSi embedded overlay'
For the flag, on RISCV we agreed in -moveraly per the High Level Design section 2.7.1.1 - Flags

[edward-jones]

Changes here:

• • Merged the separate attributes overlaycall and overlaydata into a single overlay attribute (though I may need to undo this to match the high level document)
  • Fixed to use the correct type of attribute and handle it in a less sloppy way
  • Errors/warnings messages are hopefully more descriptive now
  • Renamed option to -moverlay to match the high level document
  • It's no longer an error to use the attribute without -moverlay, you'll just get "attribute ignored" warnings
• Updated tests

Still to do:

• Writing more tests
• Warn the user to turn on -moverlay as a fix for "attribute ignored" warnings
• Rebase

[edward-jones]

I reverted some of the previous changes I made so that this patch matches the spec as currently written - this means it's two attributes again, and the diagnostic messages have been updated a bit too. The two Clang attributes match to the same LLVM attribute internally though.

This is at a stage where more review would be nice. Obviously this is gated on patches to other toolchain components, but I hope that these changes won't change too much now unless the spec also changes.

[jrtc27]

In D109372#3099947, @edward-jones wrote:

I reverted some of the previous changes I made so that this patch matches the spec as currently written - this means it's two attributes again, and the diagnostic messages have been updated a bit too. The two Clang attributes match to the same LLVM attribute internally though.

This is at a stage where more review would be nice. Obviously this is gated on patches to other toolchain components, but I hope that these changes won't change too much now unless the spec also changes.

The whole point of putting it up for review is so you get feedback about the entire direction of the spec, which was written by people who are not experts when it comes to toolchains. You’re supposed to take our feedback, relay it to them and get the draft spec revised. Otherwise, if the spec written by people who don’t know what makes sense for toolchains is regarded as holy and immutable then I’m just going to NACK this as poorly designed and something LLVM shouldn’t bow to implementing, and you’ve wasted my time asking for a full review.

[aaron.ballman]

There are still unhandled comments in the patch, btw.

clang/include/clang/Basic/Attr.td

1794

Still wondering about the naming choice.

1795

And still wondering about ObjC methods for RISCVOverlayCallAttr.

clang/include/clang/Basic/AttrDocs.td

2149

I'm confused as to why this is two attributes again. I think using a single attribute makes more sense if they're both documented to be exactly the same thing.

Also, this is missing information about the data overlay restrictions (that it be a global constant variable), and examples. Further, these docs aren't really telling me why I'd use this attribute. Are there other docs we should be linking to that describe what an overlay is, etc?

clang/lib/CodeGen/CodeGenModule.cpp

1883–1885

We should probably document that this attribute changes the function alignment.

clang/lib/Sema/SemaDeclAttr.cpp

2043–2047

This should be a LangOpt in Attr.td and not use a custom diagnostic. However, there is an interesting feature idea hiding in here for a follow-up patch, which is to generate a better diagnostic about which lang opt is required to enable the attribute.

[edward-jones]

In D109372#3099969, @jrtc27 wrote:

In D109372#3099947, @edward-jones wrote:

I reverted some of the previous changes I made so that this patch matches the spec as currently written - this means it's two attributes again, and the diagnostic messages have been updated a bit too. The two Clang attributes match to the same LLVM attribute internally though.

This is at a stage where more review would be nice. Obviously this is gated on patches to other toolchain components, but I hope that these changes won't change too much now unless the spec also changes.

The whole point of putting it up for review is so you get feedback about the entire direction of the spec, which was written by people who are not experts when it comes to toolchains. You’re supposed to take our feedback, relay it to them and get the draft spec revised. Otherwise, if the spec written by people who don’t know what makes sense for toolchains is regarded as holy and immutable then I’m just going to NACK this as poorly designed and something LLVM shouldn’t bow to implementing, and you’ve wasted my time asking for a full review.

Understood, and apologies for requesting a review without first getting the spec clarified. I had relayed feedback about naming of relocs/attributes and 1 vs 2 attributes offline, but that hadn't reached a conclusion so I had reverted to closer to the spec in the meantime. I've opened issues on the riscv-overlay repository to incorporate the feedback here.

https://github.com/riscv-software-src/riscv-overlay/issues/28
https://github.com/riscv-software-src/riscv-overlay/issues/29
https://github.com/riscv-software-src/riscv-overlay/issues/30

clang/include/clang/Basic/Attr.td

1794

I'll push for an underscore in the names if we're going to have two attributes.

I'm also wondering now whether to use overlay_function instead of overlay_call since the attribute is marking that the function exists in an overlay rather than the mechanism by which it is called.

1795

Would simply disallowing this attribute to be used with ObjC be acceptable whilst getting clarification on whether overlays should be usable from ObjC?

clang/include/clang/Basic/AttrDocs.td

2149

Would it be sufficient to document based on the restrictions defined here? As far as I'm aware LLVM documentation doesn't often refer out to external documents so I assume the attribute's documentation needs to be a self-contained summary?

I'm still not sure about one vs two attribute. One attribute is overall a bit simpler, but any diagnostics are going to need to differentiate anyway. Also, I wonder whether a single overlay attribute could confuse users if it was applied to a global function pointer - a naive user might think that the attribute applies to the type of the function rather than the Decl of the pointer.

clang/lib/Sema/SemaDeclAttr.cpp

2043–2047

Yes, the reason for the custom diagnostic is because the diagnostic explicitly requests the user enables -moverlay. If I didn't use the custom diagnostic then I could use the generic 'attribute ignored' warning with an additional diagnostic for 'note: use -moverlay to enable attribute((overlaycall))', but if the generic warning is emitted from generic code I don't know how I would attach the 'note' diagnostic to it.

clang/include/clang/Basic/Attr.td

 
 def SharedVar : SubsetSubject<Var,
                               [{S->hasGlobalStorage() && !S->getTLSKind()}],
                               "global variables">;
 
 def GlobalVar : SubsetSubject<Var,
                              [{S->hasGlobalStorage()}], "global variables">;
 
+def GlobalConst : SubsetSubject<Var,
+                               [{S->hasGlobalStorage() &&
+                                 S->getType().isConstQualified()}],
+                               "global constants">;
+
 def InlineFunction : SubsetSubject<Function,
                              [{S->isInlineSpecified()}], "inline functions">;
 
 def FunctionTmpl
     : SubsetSubject<Function, [{S->getTemplatedKind() ==
                                  FunctionDecl::TK_FunctionTemplate}],
                     "function templates">;
 

 def ObjCAutoRefCount : LangOpt<"ObjCAutoRefCount">;
 def ObjCNonFragileRuntime
     : LangOpt<"", "LangOpts.ObjCRuntime.allowsClassStubs()">;
 
 // Language option for CMSE extensions
 def Cmse : LangOpt<"Cmse">;
 
 // Defines targets for target-specific attributes. Empty lists are unchecked.
 class TargetSpec {
   // Specifies Architectures for which the target applies, based off the
   // ArchType enumeration in Triple.h.
   list<string> Arches = [];
   // Specifies Operating Systems for which the target applies, based off the
   // OSType enumeration in Triple.h
   list<string> OSes;
   // Specifies Object Formats for which the target applies, based off the
   // ObjectFormatType enumeration in Triple.h
def RISCVInterrupt : InheritableAttr, TargetSpecificAttr<TargetRISCV> {
   let Args = [EnumArgument<"Interrupt", "InterruptType",
                            ["user", "supervisor", "machine"],
                            ["user", "supervisor", "machine"],
                            1>];
   let ParseKind = "Interrupt";
   let Documentation = [RISCVInterruptDocs];
 }
 
+def RISCVOverlayCall : InheritableAttr, TargetSpecificAttr<TargetRISCV> {
+  let Spellings = [Clang<"overlay_call">];
+  let Subjects = SubjectList<[Function]>;
+  let Documentation = [RISCVOverlayCallDocs];
+}
+
+def RISCVOverlayData : InheritableAttr, TargetSpecificAttr<TargetRISCV> {
+  let Spellings = [Clang<"overlay_data">];
+  let Subjects = SubjectList<[GlobalConst]>;
+  let Documentation = [RISCVOverlayDataDocs];
+}
+
 // This is not a TargetSpecificAttr so that is silently accepted and
 // ignored on other targets as encouraged by the OpenCL spec.
 //
 // See OpenCL 1.2 6.11.5: "It is our intention that a particular
 // implementation of OpenCL be free to ignore all attributes and the
 // resulting executable binary will produce the same result."
 //
 // However, only AMD GPU targets will emit the corresponding IR
 // attribute.

clang/include/clang/Basic/AttrDocs.td

 Refer to:
 https://gcc.gnu.org/onlinedocs/gcc/RISC-V-Function-Attributes.html
 https://riscv.org/specifications/privileged-isa/
 The RISC-V Instruction Set Manual Volume II: Privileged Architecture
 Version 1.10.
   }];
 }
 
+def RISCVOverlayCallDocs : Documentation {
+  let Category = DocCatFunction;
+  let Heading = "overlay_call (RISCV)";
+  let Content = [{
+Clang supports the ``__attribute__((overlay_call))`` attribute on RISC-V
+targets. This attribute may be attached to a function definition and signifies
+that the function is placed in a software overlay. In order to use this
+attribute the ``-moverlay`` flag must also be specified during compilation.
+
+A function cannot be marked as ``overlay_call`` if it does not have external
+linkage. This includes functions marked ``static`` or defined in an
+anonymous namespace.
+
+When a function is marked with this attribute it is forced to have an
+alignment of at least 4 bytes.
+
+When a function exists in an overlay it can only be called indirectly
+through the RISC-V Overlay Runtime engine. The runtime engine is responsible
+for shuffling overlay functions into resident memory as required. The
+attribute facilities this as follows:
+
+* When referencing functions marked as ``overlay_call`` a 'token' is used
+  instead of an address. This 'token' encodes information for use by the
+  runtime engine.
+* When calling to/from an overlay function the call target (either a
+  token or the address of a resident function) is first stored to an argument
+  register, then a call is performed into the runtime engine.
+* When the address of a ``overlay_call`` function is taken the address
+  of a 'thunk' corresponding to that function is used instead. The
+  'thunk' is a stub in resident memory which can be used in a normal
+  indirect call, but redirects the call through the runtime engine.
+  }];
+}
+
+def RISCVOverlayDataDocs : Documentation {
+  let Category = DocCatVariable;
+  let Heading = "overlay_data (RISCV)";
+  let Content = [{
+Clang supports the ``__attribute__((overlay_data))`` attribute on RISC-V
+targets. This attribute may be attached to a global constant declaration
+and signifies that the value is placed in a software overlay. In order to
+use this attribute the ``-moverlay`` flag must also be specified during
+compilation.
+  }];
+}
+
 def AVRInterruptDocs : Documentation {
   let Category = DocCatFunction;
   let Heading = "interrupt (AVR)";
   let Content = [{
 Clang supports the GNU style ``__attribute__((interrupt))`` attribute on
 AVR targets. This attribute may be attached to a function definition and instructs
 the backend to generate appropriate function entry/exit code so that it can be used
 directly as an interrupt service routine.

clang/include/clang/Basic/DiagnosticDriverKinds.td

def err_drv_invalid_arch_name : Error<
   "invalid arch name '%0'">;
 def err_drv_invalid_riscv_arch_name : Error<
   "invalid arch name '%0', %1">;
 def err_drv_invalid_riscv_ext_arch_name : Error<
   "invalid arch name '%0', %1 '%2'">;
 def warn_drv_invalid_arch_name_with_suggestion : Warning<
   "ignoring invalid /arch: argument '%0'; for %select{64|32}1-bit expected one of %2">,
   InGroup<UnusedCommandLineArgument>;
+def err_drv_invalid_riscv_abi_moverlay : Error<
+  "invalid ABI '%0' when using '-moverlay'">;
 def warn_drv_avr_mcu_not_specified : Warning<
   "no target microcontroller specified on command line, cannot "
   "link standard libraries, please pass -mmcu=<mcu name>">,
   InGroup<AVRRtlibLinkingQuirks>;
 def warn_drv_avr_gcc_not_found: Warning<
   "no avr-gcc installation can be found on the system, "
   "cannot link standard libraries">,
   InGroup<AVRRtlibLinkingQuirks>;

clang/include/clang/Basic/DiagnosticSemaKinds.td

 def warn_interrupt_attribute_invalid : Warning<
    "%select{MIPS|MSP430|RISC-V}0 'interrupt' attribute only applies to "
    "functions that have %select{no parameters|a 'void' return type}1">,
    InGroup<IgnoredAttributes>;
 def warn_riscv_repeated_interrupt_attribute : Warning<
   "repeated RISC-V 'interrupt' attribute">, InGroup<IgnoredAttributes>;
 def note_riscv_repeated_interrupt_attribute : Note<
   "repeated RISC-V 'interrupt' attribute is here">;
+def err_overlay_func_external_linkage : Error<
+  "functions marked with 'overlay_call' attribute must have external linkage">;
+def err_overlay_mismatch : Error<
+  "redeclaration of %0 must %select{not |}1have the 'overlay_call' attribute">;
+def warn_attribute_ignored_overlay : Warning<
+  "%0 attribute ignored, use '-moverlay' to enable support">,
+  InGroup<IgnoredAttributes>;
 def warn_unused_parameter : Warning<"unused parameter %0">,
   InGroup<UnusedParameter>, DefaultIgnore;
 def warn_unused_but_set_parameter : Warning<"parameter %0 set but not used">,
   InGroup<UnusedButSetParameter>, DefaultIgnore;
 def warn_unused_variable : Warning<"unused variable %0">,
   InGroup<UnusedVariable>, DefaultIgnore;
 def warn_unused_but_set_variable : Warning<"variable %0 set but not used">,
   InGroup<UnusedButSetVariable>, DefaultIgnore;
 def warn_unused_local_typedef : Warning<
   "unused %select{typedef|type alias}0 %1">,
   InGroup<UnusedLocalTypedef>, DefaultIgnore;

clang/include/clang/Basic/LangOptions.def

LANGOPT(RelativeCXXABIVTables, 1, 0,
         "Use an ABI-incompatible v-table layout that uses relative references")
 
 LANGOPT(ArmSveVectorBits, 32, 0, "SVE vector size in bits")
 
 ENUM_LANGOPT(ExtendIntArgs, ExtendArgsKind, 1, ExtendArgsKind::ExtendTo32, 
              "Controls how scalar integer arguments are extended in calls "
              "to unprototyped and varargs functions")
 
+LANGOPT(Overlay, 1, 0,
+        "Enable support for use of an overlay system for calls and data "
+        "accesses")
+
 #undef LANGOPT
 #undef COMPATIBLE_LANGOPT
 #undef BENIGN_LANGOPT
 #undef ENUM_LANGOPT
 #undef COMPATIBLE_ENUM_LANGOPT
 #undef BENIGN_ENUM_LANGOPT
 #undef VALUE_LANGOPT
 #undef COMPATIBLE_VALUE_LANGOPT
 #undef BENIGN_VALUE_LANGOPT

clang/include/clang/Driver/Options.td

 def mcmodel_EQ_medlow : Flag<["-"], "mcmodel=medlow">, Group<m_riscv_Features_Group>,
   Flags<[CC1Option]>, Alias<mcmodel_EQ>, AliasArgs<["small"]>,
   HelpText<"Equivalent to -mcmodel=small, compatible with RISC-V gcc.">;
 def mcmodel_EQ_medany : Flag<["-"], "mcmodel=medany">, Group<m_riscv_Features_Group>,
   Flags<[CC1Option]>, Alias<mcmodel_EQ>, AliasArgs<["medium"]>,
   HelpText<"Equivalent to -mcmodel=medium, compatible with RISC-V gcc.">;
 def menable_experimental_extensions : Flag<["-"], "menable-experimental-extensions">, Group<m_Group>,
   HelpText<"Enable use of experimental RISC-V extensions.">;
+def moverlay : Flag<["-"], "moverlay">,
+  Group<m_Group>, Flags<[CC1Option]>,
+  HelpText<"Enable RISC-V overlay manager support">,
+  MarshallingInfoFlag<LangOpts<"Overlay">>;
 
 def munaligned_access : Flag<["-"], "munaligned-access">, Group<m_arm_Features_Group>,
   HelpText<"Allow memory accesses to be unaligned (AArch32/AArch64 only)">;
 def mno_unaligned_access : Flag<["-"], "mno-unaligned-access">, Group<m_arm_Features_Group>,
   HelpText<"Force all memory accesses to be aligned (AArch32/AArch64 only)">;
 def mstrict_align : Flag<["-"], "mstrict-align">, Alias<mno_unaligned_access>, Flags<[CC1Option,HelpHidden]>,
   HelpText<"Force all memory accesses to be aligned (same as mno-unaligned-access)">;
 def mno_thumb : Flag<["-"], "mno-thumb">, Group<m_arm_Features_Group>;

clang/lib/CodeGen/CGCall.cpp

if (isa<FunctionDecl>(TargetDecl)) {
         FuncAttrs.addAttribute("sample-profile-suffix-elision-policy",
                                "selected");
     }
   }
 
   // Collect non-call-site function IR attributes from declaration-specific
   // information.
   if (!AttrOnCallSite) {
-    if (TargetDecl && TargetDecl->hasAttr<CmseNSEntryAttr>())
+    if (TargetDecl) {
+      if (TargetDecl->hasAttr<RISCVOverlayCallAttr>())
+        FuncAttrs.addAttribute("overlay");
+      if (TargetDecl->hasAttr<CmseNSEntryAttr>())
         FuncAttrs.addAttribute("cmse_nonsecure_entry");
+    }
 
     // Whether tail calls are enabled.
     auto shouldDisableTailCalls = [&] {
       // Should this be honored in getDefaultFunctionAttributes?
       if (CodeGenOpts.DisableTailCalls)
         return true;
 
       if (!TargetDecl)

clang/lib/CodeGen/CodeGenModule.cpp

void CodeGenModule::SetLLVMFunctionAttributesForDefinition(const Decl *D,
   unsigned alignment = D->getMaxAlignment() / Context.getCharWidth();
   if (alignment)
     F->setAlignment(llvm::Align(alignment));
 
   if (!D->hasAttr<AlignedAttr>())
     if (LangOpts.FunctionAlignment)
       F->setAlignment(llvm::Align(1ull << LangOpts.FunctionAlignment));
 
+  // Overlay functions must have a minimum 4-byte alignment.
+  if (F->getAlignment() < 4 && D->hasAttr<RISCVOverlayCallAttr>())
+    F->setAlignment(llvm::Align(4));
+
   // Some C++ ABIs require 2-byte alignment for member functions, in order to
   // reserve a bit for differentiating between virtual and non-virtual member
   // functions. If the current target's C++ ABI requires this and this is a
   // member function, set its alignment accordingly.
   if (getTarget().getCXXABI().areMemberFunctionsAligned()) {
     if (F->getAlignment() < 2 && isa<CXXMethodDecl>(D))
       F->setAlignment(llvm::Align(2));
   }
if (NeedsGlobalCtor || NeedsGlobalDtor)
     EmitCXXGlobalVarDeclInitFunc(D, GV, NeedsGlobalCtor);
 
   SanitizerMD->reportGlobalToASan(GV, *D, NeedsGlobalCtor);
 
   // Emit global variable debug information.
   if (CGDebugInfo *DI = getModuleDebugInfo())
     if (getCodeGenOpts().hasReducedDebugInfo())
       DI->EmitGlobalVariable(GV, D);
+
+  if (D->hasAttr<RISCVOverlayDataAttr>())
+    GV->addAttribute("overlay");
 }
 
 void CodeGenModule::EmitExternalVarDeclaration(const VarDecl *D) {
   if (CGDebugInfo *DI = getModuleDebugInfo())
     if (getCodeGenOpts().hasReducedDebugInfo()) {
       QualType ASTTy = D->getType();
       llvm::Type *Ty = getTypes().ConvertTypeForMem(D->getType());
       llvm::Constant *GV =

clang/lib/Driver/ToolChains/Arch/RISCV.cpp

void riscv::getRISCVTargetFeatures(const Driver &D, const llvm::Triple &Triple,
   if (!getArchFeatures(D, MArch, Features, Args))
     return;
 
   // If users give march and mcpu, get std extension feature from MArch
   // and other features (ex. mirco architecture feature) from mcpu
   if (Arg *A = Args.getLastArg(options::OPT_mcpu_EQ))
     getRISCFeaturesFromMcpu(D, Triple, Args, A, A->getValue(), Features);
 
+  // Extra register reservations required to handle -moverlay
+  if (Args.hasArg(options::OPT_moverlay)) {
+    Features.push_back("+reserve-x28"); // Overlay Stack Register
+    Features.push_back("+reserve-x29"); // Overlay Stack Frames Pool Register
+    Features.push_back("+reserve-x30"); // Overlay Address Token Reg
+    Features.push_back("+reserve-x31"); // Overlay Entry Point Address Register
+  }
+
   // Handle features corresponding to "-ffixed-X" options
   if (Args.hasArg(options::OPT_ffixed_x1))
     Features.push_back("+reserve-x1");
   if (Args.hasArg(options::OPT_ffixed_x2))
     Features.push_back("+reserve-x2");
   if (Args.hasArg(options::OPT_ffixed_x3))
     Features.push_back("+reserve-x3");
   if (Args.hasArg(options::OPT_ffixed_x4))

clang/lib/Driver/ToolChains/Clang.cpp

if (const Arg *A = Args.getLastArg(clang::driver::options::OPT_mtune_EQ)) {
     Name = llvm::RISCV::resolveTuneCPUAlias(Name, Triple.isArch64Bit());
     TuneCPU = std::string(Name);
   }
 
   if (!TuneCPU.empty()) {
     CmdArgs.push_back("-tune-cpu");
     CmdArgs.push_back(Args.MakeArgString(TuneCPU));
   }
+
+  // If comrv mode is requested, pass on this flag, and produce an error if an
+  // invalid ABI has been requested
+  if (Args.getLastArg(options::OPT_moverlay)) {
+    CmdArgs.push_back("-moverlay");
+    if (ABIName != "ilp32")
+      getToolChain().getDriver().Diag(diag::err_drv_invalid_riscv_abi_moverlay)
+          << ABIName;
+  }
 }
 
 void Clang::AddSparcTargetArgs(const ArgList &Args,
                                ArgStringList &CmdArgs) const {
   sparc::FloatABI FloatABI =
       sparc::getSparcFloatABI(getToolChain().getDriver(), Args);
 
   if (FloatABI == sparc::FloatABI::Soft) {

clang/lib/Sema/SemaDecl.cpp

if (getLangOpts().MicrosoftExt) {
       Diag(OldLocation, PrevDiag);
     } else {
       Diag(New->getLocation(), diag::err_static_non_static) << New;
       Diag(OldLocation, PrevDiag);
       return true;
     }
   }
 
+  bool NewIsOverlayCall = New->hasAttr<RISCVOverlayCallAttr>();
+  bool OldIsOverlayCall = Old->hasAttr<RISCVOverlayCallAttr>();
+  if (NewIsOverlayCall != OldIsOverlayCall) {
+    Diag(New->getLocation(), diag::err_overlay_mismatch)
+        << New << OldIsOverlayCall;
+    notePreviousDefinition(Old, New->getLocation());
+    return true;
+  }
+
   if (const auto *ILA = New->getAttr<InternalLinkageAttr>())
     if (!Old->hasAttr<InternalLinkageAttr>()) {
       Diag(New->getLocation(), diag::err_attribute_missing_on_first_decl)
           << ILA;
       Diag(Old->getLocation(), diag::note_previous_declaration);
       New->dropAttr<InternalLinkageAttr>();
     }
 

clang/lib/Sema/SemaDeclAttr.cpp

static void handleCmseNSEntryAttr(Sema &S, Decl *D, const ParsedAttr &AL) {
   if (!FD->isExternallyVisible()) {
     S.Diag(AL.getLoc(), diag::warn_attribute_cmse_entry_static);
     return;
   }
 
   D->addAttr(::new (S.Context) CmseNSEntryAttr(S.Context, AL));
 }
 
+static void handleRISCVOverlayAttr(Sema &S, Decl *D, const ParsedAttr &AL) {
+  if (!S.getLangOpts().Overlay) {
+    S.Diag(AL.getRange().getBegin(), diag::warn_attribute_ignored_overlay)
+        << AL;
+    return;
+  }
+
+  if (isFunctionOrMethod(D)) {
+    const auto *ND = cast<NamedDecl>(D);
+    if (!ND->isExternallyVisible()) {
+      S.Diag(AL.getLoc(), diag::err_overlay_func_external_linkage);
+      AL.setInvalid();
+      return;
+    }
+
+    // 'overlay' on a function implies 'noinline'
+    Attr *A = ::new (S.Context) NoInlineAttr(S.Context, AL);
+    A->setImplicit(true);
+    D->addAttr(A);
+  }
+
+  if (AL.getKind() == ParsedAttr::AT_RISCVOverlayCall)
+    handleSimpleAttribute<RISCVOverlayCallAttr>(S, D, AL);
+  else
+    handleSimpleAttribute<RISCVOverlayDataAttr>(S, D, AL);
+}
+
 static void handleNakedAttr(Sema &S, Decl *D, const ParsedAttr &AL) {
   if (AL.isDeclspecAttribute()) {
     const auto &Triple = S.getASTContext().getTargetInfo().getTriple();
     const auto &Arch = Triple.getArch();
     if (Arch != llvm::Triple::x86 &&
         (Arch != llvm::Triple::arm && Arch != llvm::Triple::thumb)) {
       S.Diag(AL.getLoc(), diag::err_attribute_not_supported_on_arch)
           << AL << Triple.getArchName();
case ParsedAttr::AT_Cleanup:
     handleCleanupAttr(S, D, AL);
     break;
   case ParsedAttr::AT_NoDebug:
     handleNoDebugAttr(S, D, AL);
     break;
   case ParsedAttr::AT_CmseNSEntry:
     handleCmseNSEntryAttr(S, D, AL);
     break;
+  case ParsedAttr::AT_RISCVOverlayCall:
+  case ParsedAttr::AT_RISCVOverlayData:
+    handleRISCVOverlayAttr(S, D, AL);
+    break;
   case ParsedAttr::AT_StdCall:
   case ParsedAttr::AT_CDecl:
   case ParsedAttr::AT_FastCall:
   case ParsedAttr::AT_ThisCall:
   case ParsedAttr::AT_Pascal:
   case ParsedAttr::AT_RegCall:
   case ParsedAttr::AT_SwiftCall:
   case ParsedAttr::AT_SwiftAsyncCall:
case ParsedAttr::AT_MSAllocator:
     handleMSAllocatorAttr(S, D, AL);
     break;
 
   case ParsedAttr::AT_ArmBuiltinAlias:
     handleArmBuiltinAliasAttr(S, D, AL);
     break;
 
   case ParsedAttr::AT_AcquireHandle:
     handleAcquireHandleAttr(S, D, AL);
     break;
 
   case ParsedAttr::AT_ReleaseHandle:
     handleHandleAttr<ReleaseHandleAttr>(S, D, AL);
     break;
 
   case ParsedAttr::AT_UseHandle:
     handleHandleAttr<UseHandleAttr>(S, D, AL);
     break;
 
   case ParsedAttr::AT_EnforceTCB:
     handleEnforceTCBAttr<EnforceTCBAttr, EnforceTCBLeafAttr>(S, D, AL);
     break;

clang/test/CodeGen/riscv-overlay.c

+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py UTC_ARGS: --check-attributes
+// RUN: %clang_cc1 -triple riscv32 -moverlay -emit-llvm %s -o - \
+// RUN:    | FileCheck %s
+
+// CHECK-LABEL: @test_overlay_func(
+// CHECK-SAME: #0
+// CHECK: attributes #0 = {
+// CHECK-SAME: "overlay"
+int __attribute__((overlay_call)) test_overlay_func(void) {
+  return 5;
+}

clang/test/Driver/riscv-overlay.c

+// Check that ComRV Driver Arguments
+
+// RUN: not %clang -target riscv32 -moverlay %s -o %t.o -mabi=ilp32f 2>&1 \
+// RUN:   | FileCheck -check-prefix=INVALID-ABI %s
+// INVALID-ABI: invalid ABI 'ilp32f' when using '-moverlay'

clang/test/Misc/pragma-attribute-supported-attributes-list.test

 // CHECK-NEXT: OpenCLNoSVM (SubjectMatchRule_variable)
 // CHECK-NEXT: OptimizeNone (SubjectMatchRule_function, SubjectMatchRule_objc_method)
 // CHECK-NEXT: Overloadable (SubjectMatchRule_function)
 // CHECK-NEXT: Owner (SubjectMatchRule_record_not_is_union)
 // CHECK-NEXT: ParamTypestate (SubjectMatchRule_variable_is_parameter)
 // CHECK-NEXT: PassObjectSize (SubjectMatchRule_variable_is_parameter)
 // CHECK-NEXT: PatchableFunctionEntry (SubjectMatchRule_function, SubjectMatchRule_objc_method)
 // CHECK-NEXT: Pointer (SubjectMatchRule_record_not_is_union)
+// CHECK-NEXT: RISCVOverlayCall (SubjectMatchRule_function)
 // CHECK-NEXT: ReleaseHandle (SubjectMatchRule_variable_is_parameter)
 // CHECK-NEXT: RenderScriptKernel (SubjectMatchRule_function)
 // CHECK-NEXT: ReqdWorkGroupSize (SubjectMatchRule_function)
 // CHECK-NEXT: Restrict (SubjectMatchRule_function)
 // CHECK-NEXT: ReturnTypestate (SubjectMatchRule_function, SubjectMatchRule_variable_is_parameter)
 // CHECK-NEXT: ReturnsNonNull (SubjectMatchRule_objc_method, SubjectMatchRule_function)
 // CHECK-NEXT: ReturnsTwice (SubjectMatchRule_function)
 // CHECK-NEXT: ScopedLockable (SubjectMatchRule_record)

clang/test/Sema/riscv-overlay-attr.c

+// RUN: %clang_cc1 -triple riscv32 -moverlay -fsyntax-only -verify %s
+// RUN: %clang_cc1 -triple riscv64 -moverlay -fsyntax-only -verify %s
+
+int notAFunction __attribute__((overlay_call));
+// expected-warning@-1 {{'overlay_call' attribute only applies to functions}}
+
+void incompatForwardDecl(int x);
+void __attribute__((overlay_call)) incompatForwardDecl(int x) {}
+// expected-error@-1 {{redeclaration of 'incompatForwardDecl' must not have the 'overlay_call' attribute}}
+// expected-note@-3 {{previous definition is here}}
+
+static void staticcall() __attribute__((overlay_call)) {}
+// expected-error@-1 {{functions marked with 'overlay_call' attribute must have external linkage}}
+
+static void __attribute__((overlay_call)) staticcall2() {}
+// expected-error@-1 {{functions marked with 'overlay_call' attribute must have external linkage}}

clang/test/Sema/riscv-overlay-namespace.cpp

+// RUN: %clang_cc1 %s -triple riscv32-unknown-elf -verify -fsyntax-only -moverlay
+// RUN: %clang_cc1 %s -triple riscv64-unknown-elf -verify -fsyntax-only -moverlay
+
+namespace {
+class foo {
+public:
+  static int X() __attribute__((overlay_call)) { return 0; } // expected-error {{functions marked with 'overlay_call' attribute must have external linkage}}
+};
+} // end of anonymous namespace
+
+namespace X {
+class bar {
+public:
+  static int X() __attribute__((overlay_call)) { return 1; }
+};
+} // end of namespace X
+
+extern "C" {
+int main(void) { return foo::X() + X::bar::X(); }
+}