On Monday, 19 July 2021 at 17:20:21 UTC, kinke wrote:
You know that asm is to be avoided whenever possible, but
unfortunately, AFAIK intel-intrinsics doesn't fit the usual
'don't worry, simply compile all your code with an appropriate
-mattr/-mcpu option' recommendation, as it employs runtime
On Monday, 19 July 2021 at 17:20:21 UTC, kinke wrote:
Compiling with `-O -mtriple=i686-linux-gnu -mcpu=i686` (=> no
SSE2 by default) shows that the inlined version inside
`wrapper()` is the mega slow one, so the extra instructions
aren't applied transitively unfortunately.
Erm sorry should ha
On Monday, 19 July 2021 at 16:44:35 UTC, Guillaume Piolat wrote:
On Monday, 19 July 2021 at 10:49:56 UTC, kinke wrote:
This workaround is actually missing the clobber constraint for
`%2`, which might be problematic after inlining.
An unrelated other issue with asm/__asm is that it doesn't
f
On Monday, 19 July 2021 at 16:05:57 UTC, kinke wrote:
On Monday, 19 July 2021 at 11:16:49 UTC, Tejas wrote:
On Monday, 19 July 2021 at 10:49:56 UTC, kinke wrote:
On[snip]
Is LDC still compatible with GDC/GCC inline asm? I remember
Johan saying they will break compatibilty in the near future.
On Monday, 19 July 2021 at 10:49:56 UTC, kinke wrote:
This workaround is actually missing the clobber constraint for
`%2`, which might be problematic after inlining.
An unrelated other issue with asm/__asm is that it doesn't follow
consistent VEX encoding compared to normal compiler output.
On Monday, 19 July 2021 at 16:05:57 UTC, kinke wrote:
Is LDC still compatible with GDC/GCC inline asm? I remember
Johan saying they will break compatibilty in the near future...
I'm not aware of any of that; who'd be 'they'? GCC breaking
their syntax is IMO unimaginable. LDC supporting it (t
On Monday, 19 July 2021 at 11:39:02 UTC, Basile B. wrote:
And what about the `extern(C)` issue ? Does it make sense to be
used when the parameters are int4 ?
The original inline asm was buggy and only 'worked' by accident
(not using the 2nd input operand at all...) with extern(D)
reversed par
On Monday, 19 July 2021 at 11:16:49 UTC, Tejas wrote:
On Monday, 19 July 2021 at 10:49:56 UTC, kinke wrote:
On[snip]
Is LDC still compatible with GDC/GCC inline asm? I remember
Johan saying they will break compatibilty in the near future...
I'm not aware of any of that; who'd be 'they'? GCC
On Monday, 19 July 2021 at 10:21:58 UTC, kinke wrote:
On Sunday, 18 July 2021 at 16:32:46 UTC, Basile B. wrote:
- **=x** says "returns in whatever is has to"
- **x** (1) is the constraint for input `a`, which is passed
as operand **$0**
- **x** (2) is the constraint for input `b`, which is pass
On Monday, 19 July 2021 at 10:49:56 UTC, kinke wrote:
On[snip]
Is LDC still compatible with GDC/GCC inline asm? I remember Johan
saying they will break compatibilty in the near future...
On Monday, 19 July 2021 at 10:21:58 UTC, kinke wrote:
What works reliably is a manual mov:
```
int4 _mm_add_int4(int4 a, int4 b)
{
int4 r;
asm { "paddd %1, %2; movdqa %2, %0" : "=x" (r) : "x" (a),
"x" (b); }
return r;
}
```
This workaround is actually missing the clobber constrai
On Monday, 19 July 2021 at 10:21:58 UTC, kinke wrote:
What works reliably is a manual mov:
OK that's what I feared. It's very easy to get that wrong.
Thankfully I haven't used __asm a lot.
On Sunday, 18 July 2021 at 16:32:46 UTC, Basile B. wrote:
- **=x** says "returns in whatever is has to"
- **x** (1) is the constraint for input `a`, which is passed as
operand **$0**
- **x** (2) is the constraint for input `b`, which is passed as
operand **$1**
$0 is actually the output opera
On Sunday, 18 July 2021 at 18:48:47 UTC, Basile B. wrote:
On Sunday, 18 July 2021 at 18:47:50 UTC, Basile B. wrote:
On Sunday, 18 July 2021 at 17:45:05 UTC, Guillaume Piolat
wrote:
On Sunday, 18 July 2021 at 16:32:46 UTC, Basile B. wrote:
[...]
Thanks.
Indeed that seems to work even when in
On Sunday, 18 July 2021 at 17:45:05 UTC, Guillaume Piolat wrote:
On Sunday, 18 July 2021 at 16:32:46 UTC, Basile B. wrote:
[...]
Thanks.
Indeed that seems to work even when inline and optimized.
Registers are spilled to stack.
A minor concern is what happens when the enclosing function is
e
On Sunday, 18 July 2021 at 18:47:50 UTC, Basile B. wrote:
On Sunday, 18 July 2021 at 17:45:05 UTC, Guillaume Piolat wrote:
On Sunday, 18 July 2021 at 16:32:46 UTC, Basile B. wrote:
[...]
Thanks.
Indeed that seems to work even when inline and optimized.
Registers are spilled to stack.
A mino
On Sunday, 18 July 2021 at 16:32:46 UTC, Basile B. wrote:
Yeah I can confirm it's aweful. Took me hours to understand how
to use it a bit (my PL has [an
interface](https://styx-lang.gitlab.io/styx/primary_expressions.html#asmexpression) for LLVM asm)
You need to add a "x" to the constraint str
On Sunday, 18 July 2021 at 11:42:24 UTC, Guillaume Piolat wrote:
Is anyone versed in LLVM inline asm?
I know how to generate SIMD unary op with:
return __asm!int4("pmovsxwd $1,$0","=x,x",a);
but I struggle to generate 2-operands SIMD ops like:
return __asm!int4("paddd $1,$0","=x,x",a,
Is anyone versed in LLVM inline asm?
I know how to generate SIMD unary op with:
return __asm!int4("pmovsxwd $1,$0","=x,x",a);
but I struggle to generate 2-operands SIMD ops like:
return __asm!int4("paddd $1,$0","=x,x",a, b);
If you know how to do it => https://d.godbolt.org/z/ccM38bfM
19 matches
Mail list logo
