Odd behaviour with OP_SCAST
test-unssa.c compiles this:
extern void func(int i, ...);
void foo(int i) { func(0, (float) i, (double) i, i); }
...into this:
fpcast.64 %r3 <- (32) %arg1 scast.64 %r5 <- (32) %arg1 call func, $0, %r3, %r5, %arg1
ret
That's with the default settings. Unfortunately, with Clue, sizeof(double) == sizeof(int), so that second instruction comes out as:
scast.32 %r5 <- (32) %arg1
This then causes the simplification code in simplify_cast() to discard it:
if (size == orig_size) {
int op = (orig_type->ctype.modifiers & MOD_SIGNED) ? OP_SCAST : OP_CAST;
if (insn->opcode == op)
goto simplify;
}The end result is that my call statement turns into:
call func, $0, %r3, %arg1, %arg1
...which is wrong.
I assume that Clue's odd configuration is violating some assumption somewhere, but I'm not well-enough versed with the sparse internals to know where. It does seem odd to me that it's generating an OP_SCAST to convert the int to a double, rather than an OP_FPCAST like in the float. In the mean time, I've commented out the quoted stanza from simplify_cast() on my setup, which makes things work, but that's not really very pleasant.
Can anyone shed light on what might be happening here? Could this be a symptom of some more serious underlying bug?
Signature · 4 lines
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ───── │ │ "All power corrupts, but we need electricity." --- Diana Wynne Jones, │ _Archer's Goon_
Quoted 10 lines · David Given
The end result is that my call statement turns into:
call func, $0, %r3, %arg1, %arg1...which is wrong.
I assume that Clue's odd configuration is violating some assumption somewhere, but I'm not well-enough versed with the sparse internals to know where. It does seem odd to me that it's generating an
OP_SCASTto convert the int to a double, rather than anOP_FPCASTlike in the float.
Sparse assume that float and double have different size than int. On the linearized instruction level, it does not have the full type information any more. All it got is the size of the type. So it is tricky to distinguish int vs float.
It generate cast to double because your third argument is a double type.
Because the kernel does not have any floating pointer code. Sparse did not take floating point very seriously.
The change require the instruction to have more type information than size. I am tempting to just put a full ctype pointer there.
Chris
Chris Li wrote:
[...]
Quoted 4 lines
Sparse assume that float and double have different size than int. On the linearized instruction level, it does not have the full type information any more. All it got is the size of the type. So it is tricky to distinguish int vs float.
Here's another one; and this is with a stock unmodified sparse, too, so I know it's not my fault.
extern double pow(double x, double y);
double d(double p)
{ return pow(2, p); }
-->
call.64 %r2 <- pow, $2, %arg1 ret.64 %r2
(Again with test-unssa, which seems to be convenient for displaying intermediate code.)
[...]
Quoted 3 lines
The change require the instruction to have more type information than size. I am tempting to just put a full ctype pointer there.
In fact, that's what I've got in the private patch I'm using for Clue, although I'm only using it for determining the types of pseudos; I just hacked alloc_typed_instruction() (which knows the type) to add it. No other changes.
(This, BTW, is for a Clue backend that targets C. Yes, I can now compile C into C, which I'm sure might be useful to *someone*... due to getting ints and doubles confused some of the benchmarks are producing the wrong results, but the Whetstone one appears to be reasonably intact and *claims* that C compiled via sparse and Clue into C gets about 90% of the performance of direct compilation. Even though the benchmark is known to be poor and unreliable anyway, that's still indicative of sparse doing a pretty decent job...)
Signature · 4 lines
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ───── │ │ "All power corrupts, but we need electricity." --- Diana Wynne Jones, │ _Archer's Goon_