[Mono-devel-list] Re: Abcremoval

[Massimiliano Mantione]

On Tue, 2005-02-01 at 14:36, Willibald Krenn wrote:
>   -> Simplify example by making 'pos' unsigned int and possibly 
> introducing an overload Char indexer. (Or do some other trick so abcrem 
> can be sure that the index will never be treated as signed.)

Yes, the fact that the index could be signed is an issue, but in
any case for now both the index and the string *must* be local
variables of the method, so that SSA can track their assignments.

>   -> Turn on abcrem on methods with calls to this method (Could be some 
> separate flag like MONO_CFG_HAS_UNSIGNEDCHARINDEXER


>   -> Add the capability to abcrem to scan for strlen/getchar opcodes if 
> above flag is set. If BBs are found to be dominated by condition
> var < strlen, scan for unsigned char getter calls and operations on the 
> var; If it's safe, mark the bounds check as obsolete.

All the messy work of analyzing branch conditions and applying them
to dominated BBs is already coded, and should not be changed.
Inserting string lengths into the evaluation graph would be enough
(integer variables are obviously already there).
Then the evaluation graph must be traversed when getchar opcodes
are found (just like now for ldelema).

> BTW: Currently the string index is multiplied by two (shl) before 
> accessing the char in the string. This means that the index can not be 
> in range <0 or >0x7fffffff. (As the MSB will be shifted away.) I don't 
> know if this a bug or a feature, but effectively this means that even 
> today all accesses to string chars are '31-bits unsigned'. This means 
> that any 'bge' with System.String::get_Length() on stack can be turned 
> into an unsigned compare.. If this would be done, then abcremoval could 
> even assume signed integers to always be > 0..
> I have to confess though, that this would be some dirty trick.

Maybe I'm just picky, but it seems to me that the check is performed
on the index before the shift.
So, for strings with a length in the range 0x40000000-0x7fffffff
any index in that range would be valid when checked, but become
negative just after the shift (defying the bounds check).
Is this true?

Ciao,
  Massi