Author: Ilya Leoshkevich
Date: 2020-06-16T13:45:29+02:00
New Revision: ccd8b7b103470beb79140ecf9d6ccfaddf7fbc11
URL:
https://github.com/llvm/llvm-project/commit/ccd8b7b103470beb79140ecf9d6ccfaddf7fbc11
DIFF:
https://github.com/llvm/llvm-project/commit/ccd8b7b103470beb79140ecf9d6ccfaddf7fbc11.di
https://github.com/iii-i created https://github.com/llvm/llvm-project/pull/71668
GCC supports building individual functions with backchain using the
__attribute__((target("backchain"))) syntax, and Clang should too.
Clang translates this into the "target-features"="+backchain" attribute, and
t
https://github.com/iii-i closed https://github.com/llvm/llvm-project/pull/71668
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
iii-i wrote:
This is now causing a CI failure:
https://lab.llvm.org/buildbot/#/builders/139/builds/53143
I think I need something like `// REQUIRES: s390x-registered-target` in the new
test. I will open a PR with the fix soon.
https://github.com/llvm/llvm-project/pull/71668
___
https://github.com/iii-i created https://github.com/llvm/llvm-project/pull/71678
mbackchain-4.c requires running the backend and causes CI failures when this
target is not configured.
>From 284f2d4f844a03ece42eb6dbe7c0d889cf1b01e4 Mon Sep 17 00:00:00 2001
From: Ilya Leoshkevich
Date: Wed, 8 No
https://github.com/iii-i closed https://github.com/llvm/llvm-project/pull/71678
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: Ilya Leoshkevich
Date: 2021-07-15T12:18:48+02:00
New Revision: e34078f121a58b503d225cf715d1494117e7948b
URL:
https://github.com/llvm/llvm-project/commit/e34078f121a58b503d225cf715d1494117e7948b
DIFF:
https://github.com/llvm/llvm-project/commit/e34078f121a58b503d225cf715d1494117e7948b.di
https://github.com/iii-i created
https://github.com/llvm/llvm-project/pull/66404:
SystemZ ABI mandates that in order to pass large objects by value, one should
be place them on stack and pass the callee a pointer. Currently on LLVM IR
level it's impossible to distinguish whether a pointer argu
https://github.com/iii-i review_requested
https://github.com/llvm/llvm-project/pull/66404
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
iii-i wrote:
I just checked with a few small examples, and while the ABI does not seem to
change, the code generation looks broken for tail recursion:
```
$ cat 1.c
void baz(long double);
void quux(void) { baz((long double)1); }
$ ./bin/clang -O3 -S 1.c
$ cat 1.s
[...]
aghi%r15, -
iii-i wrote:
There is special byval handling in MSan:
```
void visitCallBase(CallBase &CB, IRBuilder<> &IRB) override {
...
for (const auto &[ArgNo, A] : llvm::enumerate(CB.args())) {
...
bool IsByVal = CB.paramHasAttr(ArgNo, Attribute::ByVal);
```
If a target does not make use of b
iii-i wrote:
I don't quite get why can't we use byval here. How is this different from
x86_64? Both s390x and x86_64 ABIs require passing large structs via a pointer,
why can x86_64 implement this using byval in LLVM and s390x can't? I agree that
currently s390x backend does not handle it prop
iii-i wrote:
Sorry, I my wording was not precise enough, it is indeed important that we
create a copy, and not pass a pointer to the original. Still, what you
described matches the s390x ABI:
```
1.2.2.3. Parameter Area
The parameter area shall be allocated by a calling function if some param
Author: Ilya Leoshkevich
Date: 2023-04-27T13:44:54+02:00
New Revision: a3e56a8792ffaf3a3d3538736e1042b8db45ab89
URL:
https://github.com/llvm/llvm-project/commit/a3e56a8792ffaf3a3d3538736e1042b8db45ab89
DIFF:
https://github.com/llvm/llvm-project/commit/a3e56a8792ffaf3a3d3538736e1042b8db45ab89.di
iii-i wrote:
Looking at the code, this is because
`Generic_GCC::GCCInstallationDetector::init()` will not try to strip any vendor
except `unknown`. This will in turn cause `s390x-ibm-linux-gnu` to not detect
GCC installation with prefix `s390x-linux-gnu`, which Debian and Ubuntu have.
On the
iii-i wrote:
This is still failing for me on Debian. The problem seems to be that
`/etc/lsb-release` does not exist. There are
```
# cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux bookworm/sid"
NAME="Debian GNU/Linux"
VERSION_CODENAME=bookworm
ID=debian
HOME_URL="https://www.debian.org/";
SU
16 matches
Mail list logo
