Odd behaviour with OP_SCAST

Odd behaviour with OP_SCAST

[David Given]

[-- Attachment #1: Type: text/plain, Size: 1557 bytes --]

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?

-- 
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ─────
│
│ "All power corrupts, but we need electricity." --- Diana Wynne Jones,
│ _Archer's Goon_


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: Odd behaviour with OP_SCAST

[Chris Li]

On Sat, Sep 6, 2008 at 2:14 PM, David Given <dg@cowlark.com> wrote:
> 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.

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

Re: Odd behaviour with OP_SCAST

[David Given]

[-- Attachment #1: Type: text/plain, Size: 1756 bytes --]

Chris Li wrote:
[...]
> 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.)

[...]
> 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...)

-- 
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ─────
│
│ "All power corrupts, but we need electricity." --- Diana Wynne Jones,
│ _Archer's Goon_


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]