[llvm-dev] [M68k] CCR usage / instruction encoding

[Renato Golin via llvm-dev]

On Fri, 27 Aug 2021 at 13:15, Ricky Taylor via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> I'm not entirely sure what the process is from here. Prepare an RFC
> for any major changes and start landing incrementally once they achieve
> some kind of consensus?


Hi Ricky,

I can't comment on the m68k stuff directly, but I can give some pointers on
the general consensus building framework.

First of all, you seem to have a pretty good idea on what the next steps
are, so that's half of the problem solved. M68k also has a pretty solid
sub-community, which makes driving local changes much easier.

On consensus building...

IIUC, most of those questions are related to the target itself and not the
generic code generation framework (sel-dag, legalizatio, MIR, etc).

The only one I remember was more generic is the code-beads that needed
table-gen support, but adding a new table-gen back-end is less
controversial than changing how sel-dag works, so not super controversial.

I'm sure there will be dependencies between wider changes and local
changes, and that's up to the community how to divide the RFCs and work.

But when bringing RFCs to the attention of the wider community, it's best
if the sub-community is already in agreement on what they want to do and
what are the valid alternatives (in case the first option doesn't work).

So, I'd encourage you to start RFCs for the local changes targeting the
sub-community, but using this list, so that other people can participate
and give opinions.

Once there is consensus on the changes you can start another RFC to a wider
audience, for example, to introduce code-beads into table-gen, with some
alternatives.

All of the local changes that don't need wider consensus can already be
implemented in the target itself, approved by the local community, as long
as it doesn't change wider behaviour or break bots, etc.

Hopefully this is helpful in some way...

cheers,
--renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210828/202ba442/attachment.html>