This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Making more builtins fold-able, and handling side-effects in args
- To: gcc at gcc dot gnu dot org
- Subject: Making more builtins fold-able, and handling side-effects in args
- From: "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>
- Date: Fri, 2 Feb 2001 16:59:21 -0500 (EST)
A couple of builtin functions (strlen, builtin_constant_p) are
fold-able at the tree stage (presumably this promotes further folding
opts and/or avoids some RTL generation.)
I'm thinking of reorganizing some of the new string builtins to do
this also. Some of them are tree-only anyway, so it makes sense to do
this.
Anyway the only stumbling block for me is arguments with side-effects,
i.e. how to handle them.
For example take __builtin_strspn(s1, "") -> (size_t)0
Currently, we call expand_expr(s1, const0_rtx, ...) so that `s1' gets
evaluated but ignored in case it had side-effects. Is creating a
COMPOUND_EXPR the right way to handle this in trees? E.g. (s1, 0)
(It seems so from reading code elsewhere...)
What if the types of the two operands don't match, (e.g. in this case
char* vs size_t), does it matter? Do I have to convert() s1?
What if we have to evaluate and ignore several arguments?
COMPOUND_EXPR only has two, do we have to build nested COMPOUND_EXPRs?
What's the right way to do that?
(s1, (s2, (s3, 0))) or (((s1, s2), s3), 0) or it doesn't matter?
Any other special gotchas I need to be aware of?
Thanks,
--Kaveh
--
Kaveh R. Ghazi Engagement Manager / Project Services
ghazi@caip.rutgers.edu Qwest Internet Solutions