This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
folding STRING_CST + INTEGER_CST
- From: Aldy Hernandez <aldyh at redhat dot com>
- To: gcc at gcc dot gnu dot org, dnovillo at redhat dot com
- Date: Sun, 23 Jun 2002 22:07:33 -0700
- Subject: folding STRING_CST + INTEGER_CST
hi guys.
[background: i'm working with diego on getting builtins SIMPLEified
correctly (AST+simple branch)].
consider this:
const char *const foo = "hello world";
strrchr (foo + 3, 'e')
with optimization, expand_builtin_strrchr() will get ["hello world"+3]
and string_constant() will fold the expression and return "lo world".
from here, we will know that we can expand the operation inline.
dandy... except in the AST branch, because we simplify into:
foo = (const char * const)(char *)"hello world";
T.1 = (const char * const)(char *)"hello world" + 3B;
T.2 = strrchr (T.1, 101);
expand_builtin_strrchr() will get [T.1] and punt to the strrchr library
function, because it doesn't know T.1 is really ["hello world"+3] (whose
value it knows: "lo world").
if we simplify builtins, these are the type of problems we encounter
(builtins punting to library functions because the arguments are now
variables, and not simple constant operations). ironic, huh? :)
question... if fold() would fold STRING_CST+INTEGER_CST (which it
currently doesn't), we'd have no problem. expand_builtin_strrchr()
would get a STRING_CST, and everything would work.
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.
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?
cheers.
aldy