On Thu, Nov 21, 2019 at 08:12:05PM -0500, Paul Koning wrote:
> > On Nov 21, 2019, at 7:42 PM, Segher Boessenkool
> > wrote:
> >
> > ...
> > Maybe i386 should implement the insn_cost hook as well? For most targets
> > that is a lot simpler to get right than rtx_cost, but allowing memory in
> > m
> On Nov 21, 2019, at 7:42 PM, Segher Boessenkool
> wrote:
>
> ...
> Maybe i386 should implement the insn_cost hook as well? For most targets
> that is a lot simpler to get right than rtx_cost, but allowing memory in
> many insns and all the different insn lengths complicates matters. At
>
On 11/22/19 1:42 AM, Segher Boessenkool wrote:
> On Thu, Nov 21, 2019 at 02:36:53PM +0100, Bernd Schmidt wrote:
>> Thanks. Just FYI, this is held up a little. I decided I'd also test on
>> x86, and there it shows a case where ix86_rtx_cost misses something: the
>> i386/pr30315.c testcase wants to c
On Thu, Nov 21, 2019 at 02:36:53PM +0100, Bernd Schmidt wrote:
> On 11/13/19 5:16 PM, Segher Boessenkool wrote:
> > On Wed, Nov 13, 2019 at 02:13:48PM +0100, Bernd Schmidt wrote:
> >> Also, it does not compute costs for jump
> >> insns, so they are always set to zero. As a consequence, any possible
On 11/13/19 5:16 PM, Segher Boessenkool wrote:
> On Wed, Nov 13, 2019 at 02:13:48PM +0100, Bernd Schmidt wrote:
>> Also, it does not compute costs for jump
>> insns, so they are always set to zero. As a consequence, any possible
>> substitution is performed if a combination into a jump is possible,
Hi!
On Wed, Nov 13, 2019 at 02:13:48PM +0100, Bernd Schmidt wrote:
> The combiner is somewhat strange about how it uses costs. If any of the
> insns involved in a comparison have a cost of 0, it does not verify that
> the substitution is cheaper.
"Cost 0" means "unknown cost". This isn't just co