Bernd Schmidt <bschm...@redhat.com> writes: > On 11/26/2015 05:22 PM, Richard Sandiford wrote: >> It also isn't suitable for optabs because the conditions are cached >> by init_optabs. I suppose we could have a separate cache for size >> and speed though. > > That sounds necessary given the existence of such insn conditions, > unless we want to disallow this practice.
Does that work though? (Before my internal_fn patches I mean.) >>> To avoid having to retest validity when moving an internal function, >>> could you just make the availability test run the predicate with both >>> for_speed and for_size options, and require that the pattern is valid >>> for both? That should give you a definitive answer as to whether you can >>> later expand the insn, and I'd call that good enough for now. >> >> That would mean we'd never use rint for x86 before expand. > > How does this compare to the situation before your internal_fn patches? > What are cases where behaviour differs and how? Ok, for rint I guess it doesn't matter. It's the TARGET_USE_FANCY_MATH_387 that would change, since tree-call-cdce.c would no longer convert (say): y = acos(x); into y = ifn_acos(x); if (...) acos (x); Maybe noone cares about TARGET_USE_FANCY_MATH_387 these days though. I still think insn conditions are the wrong place to check this. We shouldn't have a different rule for rtl insn conditions and gimple insn conditions. Thanks, Richard