[llvm-dev] [MachineScheduler] Question about IssueWidth / NumMicroOps

[Javed Absar via llvm-dev]

Hi Jonas:


The 'Single Issue', wherein an otherwise dual-issue machine can only single issue certain instruction, relies on BeginGroup/EndGroup and this change might  affect that.


- Javed

________________________________
From: Jonas Paulsson <paulsson at linux.vnet.ibm.com>
Sent: 15 May 2018 12:39:17
To: Andrew Trick
Cc: llvm-dev; Javed Absar; Florian Hahn; Matthias Braun; Hal Finkel; Ulrich Weigand
Subject: Re: [MachineScheduler] Question about IssueWidth / NumMicroOps

Hi Andy,

>> Right now it seems that BeginGroup/EndGroup is only used by SystemZ,
>> or? I see they are used in checkHazard(), which I actually don't see
>> as helpful during pre-RA scheduling for SystemZ. Could this be made
>> optional, or perhaps only done post-RA if target does post-RA
>> scheduling? SystemZ does post-RA scheduling to manage decoder
>> grouping, which is where the BeginGroup/EndGroup and
>> IssueWidth/NumMicroOps is useful. However doing this pre-RA and
>> thereby limiting the freedom of other heuristics (making less
>> instructions available) seems like a bad idea.
>
> I've worked on a few cpus in the past that had issue group
> restrictions. It seems like a natural way to handle special kinds of
> instructions. But I'm not aware of any LLVM backend that depends on it
> for preRA scheduling. If they are, hopefully they're reading this and
> will speak up.
>
> My thinking a few years back was that targets would only run post-RA
> scheduling in rare cases and only for blocks with spill code, as a
> spill-fixup pass. That's not what you, and probably others are doing,
> so if you want to make those Begin/EndGroup post-RA specific, it's
> fine with me. Or you could be more ambitious and introduce the concept
> of a post-RA specific processor resource.
>
This patch: https://reviews.llvm.org/D46870, put those checks under a
post-RA flag, and also covers the NumUOps / IssueWidth the same way.

/Jonas

> -Andy
>
>>
>>> Sorry, I don't have time to draw diagrams and tables. Hopefully you
>>> can makes sense of my long-form rambling.
>> Yes, very helpful to me :-)
>>
>> Thanks again,
>>
>> Jonas
>>
>

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180515/0a944fd7/attachment.html>