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

On 11/26/2015 05:22 PM, Richard Sandiford wrote: Bernd Schmidt writes: I wish we'd taken some more time to think through the consequences of the original internal_fn patchset. I don't think this PR shows that the approach was wrong. I think it does. Internal functions

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

On 12/01/2015 01:16 PM, Richard Biener wrote: On Tue, Dec 1, 2015 at 12:54 PM, Bernd Schmidt wrote: On 11/26/2015 05:22 PM, Richard Sandiford wrote: Bernd Schmidt writes: I wish we'd taken some more time to think through the consequences of the

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

On Tue, Dec 1, 2015 at 12:54 PM, Bernd Schmidt wrote: > On 11/26/2015 05:22 PM, Richard Sandiford wrote: >> >> Bernd Schmidt writes: >> >>> I wish we'd taken some more time to think through the consequences of >>> the original internal_fn patchset. >> >>

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

On 12/01/2015 02:43 PM, Richard Sandiford wrote: I don't think what you say is an argument that the approach is wrong. The C conditions for optabs have always been more restricted than other define_expands and define_insns, since they cannot refer to operands. When caching of optabs was added,

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

Bernd Schmidt writes: > On 11/26/2015 05:22 PM, Richard Sandiford wrote: >> Bernd Schmidt writes: >> >>> I wish we'd taken some more time to think through the consequences of >>> the original internal_fn patchset. >> >> I don't think this PR shows that

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

On 11/25/2015 01:20 PM, Richard Sandiford wrote: This series fixes PR 68432, a regression caused by my internal-functions- for-optabs series. Some of the libm optabs in i386.md have a true HAVE_* condition but conditionally FAIL if we're optimising for size: if (SSE_FLOAT_MODE_P (mode) &&

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

Bernd Schmidt writes: > On 11/25/2015 01:20 PM, Richard Sandiford wrote: >> This series fixes PR 68432, a regression caused by my internal-functions- >> for-optabs series. Some of the libm optabs in i386.md have a true HAVE_* >> condition but conditionally FAIL if we're

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

On 11/26/2015 04:13 PM, Richard Sandiford wrote: That would mean that the validity of a gimple call would depend on both the target predicates and whether the block containing the statement is optimised for size or speed. So whenever we want to test whether a gimple call is valid, we'd need to

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

Bernd Schmidt writes: > On 11/26/2015 04:13 PM, Richard Sandiford wrote: >> That would mean that the validity of a gimple call would depend on both >> the target predicates and whether the block containing the statement >> is optimised for size or speed. So whenever we want

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

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

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

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

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

This series fixes PR 68432, a regression caused by my internal-functions- for-optabs series. Some of the libm optabs in i386.md have a true HAVE_* condition but conditionally FAIL if we're optimising for size: if (SSE_FLOAT_MODE_P (mode) && TARGET_SSE_MATH && !flag_trapping_math) {

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

On Wed, Nov 25, 2015 at 1:20 PM, Richard Sandiford wrote: > This series fixes PR 68432, a regression caused by my internal-functions- > for-optabs series. Some of the libm optabs in i386.md have a true HAVE_* > condition but conditionally FAIL if we're optimising for

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

Richard Biener writes: > On Wed, Nov 25, 2015 at 1:20 PM, Richard Sandiford > wrote: >> This series fixes PR 68432, a regression caused by my internal-functions- >> for-optabs series. Some of the libm optabs in i386.md have a true HAVE_* >>