Segher Boessenkool writes:
> On Wed, Aug 09, 2017 at 05:54:40PM +0100, Richard Sandiford wrote:
>> Segher Boessenkool writes:
>> > We need it, for example, to properly cost the various define_insn_and_split
>> > (for which "type" is only an approximation, and is woefully inadequate
>> > for deter
On Wed, Aug 09, 2017 at 05:54:40PM +0100, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > We need it, for example, to properly cost the various define_insn_and_split
> > (for which "type" is only an approximation, and is woefully inadequate
> > for determining cost).
>
> But define_insn
On Tue, Aug 08, 2017 at 10:41:05AM -0600, Jeff Law wrote:
> On 08/05/2017 11:15 AM, Segher Boessenkool wrote:
> > For size cost I currently use just "length", but I haven't looked at
> > size cost much at all yet.
> I think that's fine. "length" is pretty standardized at this point and
> it's the
Segher Boessenkool writes:
> On Wed, Aug 09, 2017 at 09:56:31AM -0600, Jeff Law wrote:
>> On 08/08/2017 10:54 AM, Richard Sandiford wrote:
>> > I was thinking we should have separate attributes for size and speed
>> > from the outset. How about size_cost and speed_cost? It'd be up
>> > to the t
On Wed, Aug 09, 2017 at 09:56:31AM -0600, Jeff Law wrote:
> On 08/08/2017 10:54 AM, Richard Sandiford wrote:
> > I was thinking we should have separate attributes for size and speed
> > from the outset. How about size_cost and speed_cost? It'd be up
> > to the target to decide whether to define
Jeff Law writes:
> On 08/08/2017 10:54 AM, Richard Sandiford wrote:
For speed cost I primarily use "type", modified by the number of machine
insns a pattern generates (quite a few are split); and I get the number
of machine insns just from "length" again, which for rs6000 is easy an
On 08/08/2017 10:54 AM, Richard Sandiford wrote:
>>> For speed cost I primarily use "type", modified by the number of machine
>>> insns a pattern generates (quite a few are split); and I get the number
>>> of machine insns just from "length" again, which for rs6000 is easy and
>>> correct in most c
Jeff Law writes:
> On 08/05/2017 11:15 AM, Segher Boessenkool wrote:
>> On Sat, Aug 05, 2017 at 11:07:20AM +0100, Richard Sandiford wrote:
>>> Segher Boessenkool writes:
This series creates pattern_cost and insn_cost functions that together
replace the existing insn_rtx_cost function.
>
On 08/05/2017 11:15 AM, Segher Boessenkool wrote:
> On Sat, Aug 05, 2017 at 11:07:20AM +0100, Richard Sandiford wrote:
>> Segher Boessenkool writes:
>>> This series creates pattern_cost and insn_cost functions that together
>>> replace the existing insn_rtx_cost function.
>>>
>>> pattern_cost is l
On Sat, Aug 05, 2017 at 11:07:20AM +0100, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > This series creates pattern_cost and insn_cost functions that together
> > replace the existing insn_rtx_cost function.
> >
> > pattern_cost is like the old insn_rtx_cost function; insn_cost takes
>
Segher Boessenkool writes:
> This series creates pattern_cost and insn_cost functions that together
> replace the existing insn_rtx_cost function.
>
> pattern_cost is like the old insn_rtx_cost function; insn_cost takes
> an actual rtx_insn * as input, not just a pattern.
>
> Also a targetm.insn_c
On Tue, Aug 1, 2017 at 1:24 AM, Segher Boessenkool
wrote:
> This series creates pattern_cost and insn_cost functions that together
> replace the existing insn_rtx_cost function.
>
> pattern_cost is like the old insn_rtx_cost function; insn_cost takes
> an actual rtx_insn * as input, not just a pat
This series creates pattern_cost and insn_cost functions that together
replace the existing insn_rtx_cost function.
pattern_cost is like the old insn_rtx_cost function; insn_cost takes
an actual rtx_insn * as input, not just a pattern.
Also a targetm.insn_cost is added, which targets can use to i
13 matches
Mail list logo
