This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]