Hi Richard,
Apologies as I replied w/o looking for another update on the thread first.
On 10/30/24 11:35, Richard Sandiford wrote:
I'm not saying that the algorithm gets the decision right for cactu
when tuning for in-order CPU X and running on that same CPU X.
But it seems like th
Vineet Gupta writes:
> On 10/30/24 10:25, Jeff Law wrote:
>> On 10/30/24 9:31 AM, Richard Sandiford wrote:
>>> That might need some finessing of the name. But I think the concept
>>> is right. I'd rather base the hook (or param) on a general concept
>>> like that rather than a specific "wide vs
On 10/30/24 10:25, Jeff Law wrote:
> On 10/30/24 9:31 AM, Richard Sandiford wrote:
>> That might need some finessing of the name. But I think the concept
>> is right. I'd rather base the hook (or param) on a general concept
>> like that rather than a specific "wide vs narrow" thing.
> Agreed. Na
Jeff Law writes:
> On 10/30/24 9:31 AM, Richard Sandiford wrote:
>
>>
>> OK (and yeah, I can sympathise). But I think there's an argument that,
>> if you're scheduling for one in-order core using the pipeline of an
>> unrelated core, that's effectively scheduling for the core as though
>> it wer
On 10/30/24 9:31 AM, Richard Sandiford wrote:
OK (and yeah, I can sympathise). But I think there's an argument that,
if you're scheduling for one in-order core using the pipeline of an
unrelated core, that's effectively scheduling for the core as though
it were out-of-order. In other words
Jeff Law writes:
> On 10/30/24 8:44 AM, Richard Sandiford wrote:
>
>>> But the data from the BPI (spacemit k1 chip) is an in-order core.
>>> Granted we don't have a good model of its pipeline, but it's definitely
>>> in-order.
>>
>> Damn :) (I did try to clarify what was being tested earlier, bu
On 10/30/24 8:44 AM, Richard Sandiford wrote:
But the data from the BPI (spacemit k1 chip) is an in-order core.
Granted we don't have a good model of its pipeline, but it's definitely
in-order.
Damn :) (I did try to clarify what was being tested earlier, but the
response wasn't clear.)
So
Jeff Law writes:
> On 10/30/24 4:05 AM, Richard Sandiford wrote:
>> Vineet Gupta writes:
>>> On 10/29/24 11:51, Wilco Dijkstra wrote:
Hi Vineet,
> I agree the NARROW/WIDE stuff is obfuscating things in technicalities.
Is there evidence this change would make things significantly wor
On 10/30/24 4:05 AM, Richard Sandiford wrote:
Vineet Gupta writes:
On 10/29/24 11:51, Wilco Dijkstra wrote:
Hi Vineet,
I agree the NARROW/WIDE stuff is obfuscating things in technicalities.
Is there evidence this change would make things significantly worse for
some targets?
Honestly I
Vineet Gupta writes:
> On 10/29/24 11:51, Wilco Dijkstra wrote:
>> Hi Vineet,
>>> I agree the NARROW/WIDE stuff is obfuscating things in technicalities.
>> Is there evidence this change would make things significantly worse for
>> some targets?
>
> Honestly I don't think this needs to be behind a
On 10/29/24 1:14 PM, Vineet Gupta wrote:
On 10/29/24 11:51, Wilco Dijkstra wrote:
Hi Vineet,
I agree the NARROW/WIDE stuff is obfuscating things in technicalities.
Is there evidence this change would make things significantly worse for
some targets?
Honestly I don't think this needs to be
On 10/29/24 10:57 AM, Vineet Gupta wrote:
Certainly open to more ideas on the naming, which I think will impact
the documentation & comments as well.
And to be 100% clear, no concerns with the behavior of the patch, it's
really just the naming convention, documentation/comments.
Thoughts?
On 10/29/24 11:51, Wilco Dijkstra wrote:
> Hi Vineet,
>> I agree the NARROW/WIDE stuff is obfuscating things in technicalities.
> Is there evidence this change would make things significantly worse for
> some targets?
Honestly I don't think this needs to be behind any toggle or made optional at
Hi Vineet,
> I agree the NARROW/WIDE stuff is obfuscating things in technicalities.
Is there evidence this change would make things significantly worse for
some targets? I did a few runs on Neoverse V2 with various options and
it looks beneficial both for integer and FP. On the example and option
On 10/29/24 08:05, Jeff Law wrote:
> On 10/20/24 1:40 PM, Vineet Gupta wrote:
>> Pressure senstive scheduling seems to prefer "wide" schedules with more
>> parallelism tending to more spills. This works better for in-order
>> cores [1][2].
> I'm not really sure I'd characterize it that way, but I c
On 10/20/24 1:40 PM, Vineet Gupta wrote:
Pressure senstive scheduling seems to prefer "wide" schedules with more
parallelism tending to more spills. This works better for in-order
cores [1][2].
I'm not really sure I'd characterize it that way, but I can also see how
you got to the wide vs nar
Pressure senstive scheduling seems to prefer "wide" schedules with more
parallelism tending to more spills. This works better for in-order
cores [1][2].
The Excess Change Cost (ECC) of an insn, essentially a proxy of register
pressure attributed to an insn, deliberately ignores negative values
(Pr
17 matches
Mail list logo
