[PATCH] D110900: Triple: Add RedHat vendor
Aaron Puchert via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Tue Feb 28 16:01:15 PST 2023
aaronpuchert added a comment.
Herald added a project: All.
In D110900#3044159 <https://reviews.llvm.org/D110900#3044159>, @aaronpuchert wrote:
> Can't speak for RedHat, but on SUSE we have
>
> > gcc -dumpmachine
> x86_64-suse-linux
> > clang -dumpmachine
> x86_64-unknown-linux-gnu
Not anymore. I've switched the default target triple to `<arch>-suse-linux` some time ago (except for ARM 6 & 7, where we specify the ABI), and haven't gotten any complaints about it.
There is only one issue that I have observed, and patching `isGNUEnvironment` fixes it: we get a function call for `fma` even if it's available in hardware, apparently because `Sema::AddKnownFunctionAttributes` in SemaDecl.cpp doesn't add `__attribute__(const))` if `isGNUEnvironment` returns false.
================
Comment at: llvm/include/llvm/ADT/Triple.h:532
bool isGNUEnvironment() const {
EnvironmentType Env = getEnvironment();
return Env == Triple::GNU || Env == Triple::GNUABIN32 ||
----------------
aaronpuchert wrote:
> Since `getEnvironment` is also public, shouldn't we fix it there? Otherwise I fear this might lead to inconsistencies. (That is, `getEnvironment()` returning `UnknownEnvironment`, but `isGNUEnvironment()` returning `true`.) Perhaps we should even do something like this:
>
> ```
> bool isGNUEnvironment() const {
> return isGNU(getEnvironment());
> }
> static bool isGNU(EnvironmentType Env) {
> // ...
> }
> ```
>
> to clarify that `isGNUEnvironment` really only depends on the environment.
>
> Possibly we should even set `Environment = Triple::GNU;` in the constructor for vendors known to use GNU by default without declaring it?
>
> That's currently done in some cases, though I'm not sure if the members should contain the properties as declared, or the actual values.
I've been thinking about this a bit more and think what you did here is actually correct. The triple doesn't explicitly specify GNU, but we're "implicitly" in a GNU environment. And if one wants to check whether they're in some kind of GNU environment, they'd probably use this function instead of enumerating all the GNU* environments anyway. Most of the occurrences of `Triple::GNU` are actually in connection with `Triple::Win32`. Places where there might be issues:
* `ARMTargetInfo::ARMTargetInfo` has a `switch (Triple.getEnvironment())`. But I'm not familiar with this and haven't observed any issues.
* `computeTargetTriple` in `clang/lib/Driver/Driver.cpp` could be an issue with `-m32` or `-m64`.
================
Comment at: llvm/include/llvm/ADT/Triple.h:532-536
EnvironmentType Env = getEnvironment();
return Env == Triple::GNU || Env == Triple::GNUABIN32 ||
Env == Triple::GNUABI64 || Env == Triple::GNUEABI ||
- Env == Triple::GNUEABIHF || Env == Triple::GNUX32;
+ Env == Triple::GNUEABIHF || Env == Triple::GNUX32 ||
+ (getVendor() == Triple::RedHat && Env == Triple::UnknownEnvironment);
----------------
aaronpuchert wrote:
> aaronpuchert wrote:
> > Since `getEnvironment` is also public, shouldn't we fix it there? Otherwise I fear this might lead to inconsistencies. (That is, `getEnvironment()` returning `UnknownEnvironment`, but `isGNUEnvironment()` returning `true`.) Perhaps we should even do something like this:
> >
> > ```
> > bool isGNUEnvironment() const {
> > return isGNU(getEnvironment());
> > }
> > static bool isGNU(EnvironmentType Env) {
> > // ...
> > }
> > ```
> >
> > to clarify that `isGNUEnvironment` really only depends on the environment.
> >
> > Possibly we should even set `Environment = Triple::GNU;` in the constructor for vendors known to use GNU by default without declaring it?
> >
> > That's currently done in some cases, though I'm not sure if the members should contain the properties as declared, or the actual values.
> I've been thinking about this a bit more and think what you did here is actually correct. The triple doesn't explicitly specify GNU, but we're "implicitly" in a GNU environment. And if one wants to check whether they're in some kind of GNU environment, they'd probably use this function instead of enumerating all the GNU* environments anyway. Most of the occurrences of `Triple::GNU` are actually in connection with `Triple::Win32`. Places where there might be issues:
>
> * `ARMTargetInfo::ARMTargetInfo` has a `switch (Triple.getEnvironment())`. But I'm not familiar with this and haven't observed any issues.
> * `computeTargetTriple` in `clang/lib/Driver/Driver.cpp` could be an issue with `-m32` or `-m64`.
Perhaps we should make this a switch?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D110900/new/
https://reviews.llvm.org/D110900
More information about the llvm-commits
mailing list