[llvm] [clang] New calling convention preserve_none (PR #76868)
@@ -416,6 +416,12 @@ added in the future: This calling convention, like the `PreserveMost` calling convention, will be used by a future version of the ObjectiveC runtime and should be considered experimental at this time. +"``preserve_nonecc``" - The `PreserveNone` calling convention +This calling convention doesn't preserve any general registers. So all +general registers are caller saved registers. It also uses all general +registers to pass arguments. This attribute doesn't impact floating-point pinskia wrote: I suspect this should say any `non-general purpose registers (e.g. floating point registers, on x86 XMMs/YMMs)`. Rather than `floating-point registers`. Also isn't this just a hack to increase the number of registers used to pass arguments? If so there has to be a better way of doing this. Maybe a non-exposed attribute which is used only for non-exposed functions? e.g. on x86 (not 64bit), regparm could be used internally there. https://github.com/llvm/llvm-project/pull/76868 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] nolock/noalloc attributes (PR #84983)
pinskia wrote:
One question since the attribute is applied to types is there a way to get the
nolock/noalloc from type?.
e.g.
```
template [[nolock(T)]] void f(T a) { a(); }
```
Will the above work or is there no way to implement that currently?
Since you mention it is attached to the type, is it mangled then differently.
e.g.:
```
template [[nolock]] void f(T a) { a(); }
[[nolock(true)]] void g(void);
[[nolock(false)]] void h(void);
void m()
{
f(g);
f(h);
}
```
Does the above f calls to 2 different functions?
Or is the nolock/noalloc dropped from function types for templates/auto usage?
What about decltype (or the GNU extension __typeof__) usage is it dropped there
too?
https://github.com/llvm/llvm-project/pull/84983
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [ARM] __ARM_ARCH macro definition fix (PR #81493)
pinskia wrote: Note the corresponding GCC bug is at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99312 (and there was a patch posted but never reviewed; https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566322.html). https://github.com/llvm/llvm-project/pull/81493 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] nolock/noalloc attributes (PR #84983)
pinskia wrote: Does it make sense to have some C testcases too? Likewise some testcases testing the __attribute__ style attribute? I would say more testcases the better really. https://github.com/llvm/llvm-project/pull/84983 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] [libcxx] [C++17] Support __GCC_[CON|DE]STRUCTIVE_SIZE (PR #89446)
pinskia wrote: https://github.com/itanium-cxx-abi/cxx-abi/issues/74 https://github.com/llvm/llvm-project/pull/89446 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang] deprecate frelaxed-template-template-args, make it on by default (PR #89807)
pinskia wrote: Reference to https://github.com/llvm/llvm-project/issues/55894 . https://github.com/llvm/llvm-project/pull/89807 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [AArch64] Add support for Qualcomm Oryon processor (PR #91022)
pinskia wrote: Note the corresponding GCC patch: https://gcc.gnu.org/pipermail/gcc-patches/2024-May/650664.html https://github.com/llvm/llvm-project/pull/91022 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [AArch64] Support preserve_none calling convention (PR #91046)
pinskia wrote: I don't think you can use x16 and x17 for argument passing due to them being reserved for PLTs and call veneers. https://github.com/llvm/llvm-project/pull/91046 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [llvm] [AArch64] Support preserve_none calling convention (PR #91046)
@@ -5658,17 +5658,20 @@ experimental at this time.
def PreserveNoneDocs : Documentation {
let Category = DocCatCallingConvs;
let Content = [{
-On X86-64 target, this attribute changes the calling convention of a function.
+On X86-64 and AArch64 targets, this attribute changes the calling convention
of a function.
The ``preserve_none`` calling convention tries to preserve as few general
registers as possible. So all general registers are caller saved registers. It
also uses more general registers to pass arguments. This attribute doesn't
-impact floating-point registers (XMMs/YMMs). Floating-point registers still
-follow the c calling convention.
-
-- Only RSP and RBP are preserved by callee.
-
-- Register RDI, RSI, RDX, RCX, R8, R9, R11, R12, R13, R14, R15 and RAX now can
- be used to pass function arguments.
+impact floating-point registers.
+
+- On X86-64, only RSP and RBP are preserved by the callee.
+ Registers RDI, RSI, RDX, RCX, R8, R9, R11, R12, R13, R14, R15 and RAX now can
+ be used to pass function arguments. Floating-point registers (XMMs/YMMs)
still
+ follow the C calling convention.
+- On AArch64, only LR and FP are preserved by the callee.
+ Registers X19-X28 and X0-X17 are used to pass function arguments.
pinskia wrote:
Even though you removed X16/X17 you seemly forgot to update the documentation.
https://github.com/llvm/llvm-project/pull/91046
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] nonblocking/nonallocating attributes (was: nolock/noalloc) (PR #84983)
pinskia wrote: Well assume attribute is a good example of where gcc and clang disagree and might cause issues. Gcc implemented the assume attribute just the same as the standard one. While clang implemented before standardization and now they differ and could cause issues. This is why I requested using clang_ here. https://github.com/llvm/llvm-project/pull/84983 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [C] Disable use of NRVO (PR #101038)
pinskia wrote: Note the C++ issue with NRVO is https://cplusplus.github.io/CWG/issues/2868.html . https://github.com/llvm/llvm-project/pull/101038 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang][sema] Add support and documentation for `__has_extension(c_fixed_enum)` (PR #117507)
pinskia wrote: >From my point of view this looks like a decent documentation of this >extension. Note I filed the original bug because I noticed both GCC and clang >didn't document this extension. (I filed GCC here: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117689 which I got try fix next >week). https://github.com/llvm/llvm-project/pull/117507 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [TBAA] Don't emit pointer-tbaa for void pointers. (PR #122116)
pinskia wrote:
Note GCC already treats `void*` as being compatiable with all other pointers
and has since GCC 6 (when it started to disambiguates accesses to different
pointers). I don't think it is documented though.
Another example where clang/LLVM handles void pointers differently from GCC:
```
extern void abort(void);
int f(void *a, int **b, void *c)
{
void **e = a;
int d = **b;
*e = c;
return d + **b;
}
int main()
{
int d = 1;
int ff = 0;
int *e = &d;
if (f(&e, &e, &ff) != 1)
abort();
}
```
https://github.com/llvm/llvm-project/pull/122116
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [TBAA] Don't emit pointer-tbaa for void pointers. (PR #122116)
pinskia wrote: Note GCC's testcase testsuite/gcc.dg/alias-14.c is testcase for this extension: "as an extension we consider void * universal. Writes to it should alias." https://github.com/llvm/llvm-project/pull/122116 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang] Introduce __builtin_is_modifiable_lvalue() (PR #132524)
@@ -0,0 +1,17 @@ +// RUN: %clang_cc1 -std=c99 -fsyntax-only -verify %s pinskia wrote: > This feels like a pretty bare bones set of tests, I think we can do better. > > For example, it has been discussed that there should not be side effects, > let's verify that. Above in a comment `(int)var` was mentioned, we should > verify that. How about return values from functions which was also mentioned > above, we should verify it is usable in constant expressions etc Agreed. I have not written the testcases for GCC patch yet but I will make sure Kees's clang implementation matches up. Since GCC is in stage 4 and will be for one more month I am not going to submit the GCC patch until then so we have plenty of time to get agreement on the semantics of the builtin and such. https://github.com/llvm/llvm-project/pull/132524 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Sema] Fix tautological bounds check warning with -fwrapv (PR #120480)
pinskia wrote: Shouldn't this be part of -Wstrict-overflow instead of -Wtautological-compare ? https://github.com/llvm/llvm-project/pull/120480 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libunwind] libunwind: Do not use __attribute__((target("gcs"))) with non-clang … (PR #138077)
pinskia wrote:
Actually GCC 15 does support GCS, the syntax is just
`__attribute__((target("+gcs")))` Note the + there. The error message is clear
too.
https://github.com/llvm/llvm-project/pull/138077
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [C] Add -Wjump-bypasses-init (PR #138009)
pinskia wrote: Just FYI, the GCC name of the option is -Wjump-misses-init . https://github.com/llvm/llvm-project/pull/138009 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang] Add __has_target_builtin macro (PR #126324)
pinskia wrote:
What is the definition of current target? Is it the current subtarget? Or is it
returning true even when NOT using `#pragma GCC target` (or the target
attribute) even if the builtin is not work for the subtarget?
This is unrelated to offloading but is similar issue.
With respect to offloading, the same question comes into play for the offload
target too.
I am not defintely the wrong person to ask about offloading and
`__has_{*}builtin` as I try to stay away from the offloading stuff.
https://github.com/llvm/llvm-project/pull/126324
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang] Add __has_target_builtin macro (PR #126324)
pinskia wrote: Maybe the problem with the name I am having is the word `has`. Maybe `__can_use_builtin` seems like a better name. And that seems like would be a good context sensative clue. https://github.com/llvm/llvm-project/pull/126324 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang] Add __has_target_builtin macro (PR #126324)
pinskia wrote: I submitted https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118882 to ask the other GCC folks about what they think is a good idea because I have no other thoughts on this; I just think something needs to be done. https://github.com/llvm/llvm-project/pull/126324 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang] Introduce __builtin_is_modifiable_lvalue() (PR #132524)
pinskia wrote: Note the GCC implementtion of __builtin_is_modifiable_lvalue that I have implemented (unlike __builtin_constant_p which in some but not all cases) throws away the full expression that is inside __builtin_is_modifiable_lvalue since it is fully implemented in the parser rather than a mix of the middle-end and parser. In a similar way __builtin_choose_expr is handled for the non chosen side. https://github.com/llvm/llvm-project/pull/132524 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [Clang] Introduce __builtin_is_modifiable_lvalue() (PR #132524)
@@ -12985,6 +12985,16 @@ bool IntExprEvaluator::VisitBuiltinCallExpr(const
CallExpr *E,
assert(Src.isInt());
return Success((Src.getInt() & (Alignment - 1)) == 0 ? 1 : 0, E);
}
+ case Builtin::BI__builtin_is_modifiable_lvalue: {
+const Expr *Arg = E->getArg(0);
+SpeculativeEvaluationRAII SpeculativeEval(Info);
+IgnoreSideEffectsRAII Fold(Info);
+
+SourceLocation OrigLoc = Arg->getExprLoc();
+bool IsLValue = Arg->IgnoreCasts()->isModifiableLvalue(
pinskia wrote:
I suspect `IgnoreCasts()` should be removed here. Otherwise `(int)var` would be
allowed. As we talked about on mastodon. The GCC implemention does not ignore
casts.
https://github.com/llvm/llvm-project/pull/132524
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
