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]

Re: Making more builtins fold-able, and handling side-effectsin args


>>>>> "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

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