search for: zcast

That and the possibility of differently sized pointers made me hesitate to dive into implementing this. I guess nailing it down to be the platform equivalent of size_t would be sensible here. On Mon, Aug 9, 2010 at 1:37 PM, Eugene Toder <eltoder at gmail.com> wrote: > Small nitpick: size_t is not guaranteed to be large enough to hold a > pointer (only an array index, which can be

I looked through the "intp" thread. I don't really want to start that argument up again, but my immediate thought would be to create a new class of "picked-by-the-target" integer types (equivelents of size_t, intptr_t, etc...), and two new instructions, zcast and scast, which are only valid in the context of casting to / from integer types of unknown sizes. To begin with, most passes could probably ignore (or otherwise pass pass over) these instructions. The resolution of these types would only happen in the legalize phase in the SelectionDAG. Just m...

...n't really want to start that argument up again, but my immediate >>> > thought would be to create a new class of "picked-by-the-target" integer >>> > types (equivelents of size_t, intptr_t, etc...), and two new >>> > instructions, >>> > zcast and scast, which are only valid in the context of casting to / >>> > from >>> > integer types of unknown sizes.  To begin with, most passes could >>> > probably >>> > ignore (or otherwise pass pass over) these instructions.  The resolution >>&gt...