This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Making more builtins fold-able, and handling side-effects in args
- To: ghazi at caip dot rutgers dot edu
- Subject: Re: Making more builtins fold-able, and handling side-effects in args
- From: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- Date: Fri, 2 Feb 01 17:22:59 EST
- Cc: gcc at gcc dot gnu dot org
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)
Yes, most certainly.
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?
You should. It's always best to have the tree as type-correct as possible.
What if we have to evaluate and ignore several arguments?
COMPOUND_EXPR only has two, do we have to build nested COMPOUND_EXPRs?
Yes.
What's the right way to do that?
(s1, (s2, (s3, 0))) or (((s1, s2), s3), 0) or it doesn't matter?
It doesn't matter: whichever is easier.