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]

Making more builtins fold-able, and handling side-effects in args


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

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