Re: [PATCH 03/15] Add type information to struct instruction.

["Christopher Li" <sparse@chrisli.org>]

On Wed, Dec 24, 2008 at 3:01 PM, David Given <dg@cowlark.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Christopher Li wrote:
> [...]
>> OK, if it is just for OP_LOAD. Will this attached patch solve your problem?
>>
>> Instead of adding type to every instruction. It just add that for the OP_LOAD
>> instruction in insn->orig_type. If that works for you. I am very glad to reclaim
>> the space back on instruction structure.
>
> Sorry, I'm not at home right now and can't test this (and probably won't
> until New Year, though I'll have a go).

No problem. Have a nice Christmas.

>
> Also, I don't know if it *is* just of OP_LOAD. That's just the one I
> remember from looking back at old email. I think the issue is that
> OP_LOAD breaks the chain of pseudo->definer->pseudo->definer that I was
> using to determine the intrinsic type of the pseudo, but there may be
> other instructions that do this as well.

I hope that is the only one. Let me know if you find out there is
more instructions.

>
> I'd imagine that nobody else has come across this yet because most
> people are happy using the size to distinguish between different types;
> but (assuming that I've remembered this correctly) this'll bite anyone
> who needs to distinguish floats from int32s of doubles from int64s.

Right, other than the size, we need to distinguish between:
(sign/unsign) integer, floating point, pointers.
That is why we even have three type of cast instruction.
CAST, CASTFP and CASTPTR. They can generate fairly different
code.


> If space is really an issue, would it make sense therefore to replace
> the insn->size (and symbol->size etc) field with a ->type field pointing
> at the defining symbol for the type? Anyone who needs the type can get
> it from the defining symbol, plus all the other information that people
> like me need would be available, and may also simplify other code. (I
> could throw away a complete source file!)

Right, that is what I am purposing in previous email as well.
It looks have more code up front. But it can simplify the back end
who actually going to use it. It is actually much easier to do it
from front end while initializing those symbols.

Chris