efriedma-quic wrote:
byval generally results in worse code. It has two problems:
- The copy is invisible. Having the copy explicitly visible means we can
optimize the code involved in the copy (sometimes we can eliminate it, or parts
of it).
- Gluing the allocation to the call means stack lay
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
efriedma-quic wrote:
> Both s390x and x86_64 ABIs require passing large structs via a pointer
Wrong. x86_64 passes structs by value (copying the data into the argument
list). It just looks like a pointer in the IR because LLVM can't really handle
large values in registers.
---
The semantic
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
efriedma-quic wrote:
In any case:
- We absolutely can't use byval here.
- If you think we need a new attribute for this, please start a Discourse
thread to get some feedback. (I'm still not understanding what you're trying
to fix here, but maybe additional perspectives would help bridge the g
efriedma-quic wrote:
There's a special case in the msan handling precisely because byval makes the
ABI different. (If you look at the x86 code, you'll see that the generated
code with byval is significantly different.)
I don't think I know enough about dfsan to follow that argument.
https://
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
efriedma-quic 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:
I'd guess the SystemZ backend doesn't implement byval properly (since it's not
required for the C calling convention, probably nobo
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, -
efriedma-quic wrote:
byval changes the calling convention: instead of passing a pointer, it copies
the pointed-to value into the argument list.
It's not clear to me why msan cares about whether a pointer is an implicit or
explicit value... but if it does, we'd want to use an attribute that doe
uweigand wrote:
This looks correct to me. I'm just wondering if there's any unexpected change
of generated code due to this - did you do a comparison before/after of some
larger code bases?
https://github.com/llvm/llvm-project/pull/66404
___
cfe-com
llvmbot wrote:
@llvm/pr-subscribers-clang
Changes
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 argument was there i
https://github.com/llvmbot labeled
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
https://github.com/llvmbot labeled
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
https://github.com/llvmbot labeled
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
https://github.com/llvmbot labeled
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
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
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
18 matches
Mail list logo
