Re: [PR68432 00/26] Handle size/speed choices for internal functions

[Richard Sandiford <richard dot sandiford at arm dot com>]

Bernd Schmidt <bschmidt@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