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-effectsin args
- To: ghazi at caip dot rutgers dot edu
- Subject: Re: Making more builtins fold-able, and handling side-effectsin args
- From: Mark Mitchell <mark at codesourcery dot com>
- Date: Sat, 03 Feb 2001 15:01:54 -0800
- Cc: gcc at gcc dot gnu dot org
- Organization: CodeSourcery, LLC
- References: <200102022159.QAA24215@caip.rutgers.edu>
>>>>> "Kaveh" == Kaveh R Ghazi <ghazi@caip.rutgers.edu> writes:
Kaveh> Currently, we call expand_expr(s1, const0_rtx, ...) so that `s1' gets
Kaveh> evaluated but ignored in case it had side-effects. Is creating a
Kaveh> COMPOUND_EXPR the right way to handle this in trees? E.g. (s1, 0)
Kaveh> (It seems so from reading code elsewhere...)
Yes, that's sensible. Make sure there remains only one copy of s1 in
the result.
Kaveh> What if the types of the two operands don't match, (e.g. in this case
Kaveh> char* vs size_t), does it matter? Do I have to convert() s1?
No.
Kaveh> What if we have to evaluate and ignore several arguments?
Kaveh> COMPOUND_EXPR only has two, do we have to build nested COMPOUND_EXPRs?
Kaveh> What's the right way to do that?
Kaveh> (s1, (s2, (s3, 0))) or (((s1, s2), s3), 0) or it doesn't matter?
Either is fine. I like choice 2 better, since it makes it easier for
the subsequent folding to find the 0 at the end.
Also, note that you might want to do:
s3, s2, s1, 0
on a machine that normally evaluates arguments in that order, so that
there are no evaluation order gotchas between ordinary calls and the
builtin expanded calls. Of course, C doesn't define an order, so code
that depends on this is pretty much broken -- but still principle
of least of surprise is good.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com