leonardchan added a comment.

In D93668#2492081 <https://reviews.llvm.org/D93668#2492081>, @phosek wrote:
> I agree that if we want to allow selecting C++ ABI only, a flag like 
> `-fc++abi=` with some additional checks to disallow invalid combinations is 
> better. The question is whether we want to allow that in the first place? The 
> motivation behind this change is to support generating code that's ABI 
> compatible with the code generated by GCC. That could be expressed using the 
> target triple (one idea is to use `*-*-fuchsia-gnu`), which would cover both 
> C++ ABI as well as other aspects of the ABI (for example it could also 
> disable SafeStack/ShadowCallStack) so developers don't need to concern 
> themselves with all the details of the ABI, which could evolve over time 
> expanding the set of flags you'd need to pass to the compiler to generate 
> code that's ABI compatible with GCC.

In the context of representing the fourth component of the triple to represent 
the *platform* ABI rather than exclusively the C++ ABI, I think this would make 
sense. Using this other component would essentially just mean adding another 
layer of default flag configurations whose default values differ from those set 
by the first three components. I think we'd only want to have this extra layer 
if we have a sizable number of flags that we'd want separate from the default 
triple.

For our case, I think this mainly includes

- the C++ ABI (which encompasses "return this" on ctors/dtors and relative 
vtables),
- SS/SCS
- and maybe the PIC-friendly lookup tables if that ends up getting hidden 
behind a switch

but there could be new ABI changes down the line that could fall under this (or 
others that exist now but don't come to mind right now). Unless I'm missing 
some other features, this list seems fairly small and might not be worth 
tucking this under something that's meant to control a set of flags, but if we 
care more about being preventative from adding new flags, then it seems fine to 
just stick with using the triple.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D93668/new/

https://reviews.llvm.org/D93668

_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to