Re: folding STRING_CST + INTEGER_CST

["Joseph S. Myers" <jsm28 at cam dot ac dot uk>]

On Sun, 23 Jun 2002, Aldy Hernandez wrote:

>   foo = (const char * const)(char *)"hello world";
>   T.1 = (const char * const)(char *)"hello world" + 3B;
>   T.2 = strrchr (T.1, 101);

> is there a reason why we don't fold this case?  it seems silly we don't 
> fold "hello"+3 into "lo", and simplify some of the builtins code.

We'd need to ensure that "hello"+3 != "HELlo"+3 (while still having "lo"
== "lo"), as well as that (("hello"+3)-3) == "hello", and so on.

> if there's a reason why we don't fold, then what is suggested?  is
> there a way of annotating trees with something like an EXPR_EQUIV tree?

Perhaps we should be able to optimize the simplified code above if it were
explictly written, as well.  This would require more complicated analysis
to determine whether the arguments to the built-in function were constant
strings, but it might be useful anyway to do such analysis on trees at an
earlier stage.  (You would then get into
* Determine that a string is constant.
* Thus, evaluate __builtin_strlen on it to a constant.
* That now means some other string or number derived from the result of
__builtin_strlen is constant.
* ...
* I've no idea how useful this would be in optimizing real programs, or at 
what compile-time cost.)

-- 
Joseph S. Myers
jsm28@cam.ac.uk