[llvm-dev] RFC: CfgTraits/CfgInterface design discussion

Renato Golin via llvm-dev llvm-dev at lists.llvm.org
Mon Oct 26 11:46:32 PDT 2020


On Sat, 24 Oct 2020 at 23:13, Nicolai Hähnle via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Maybe David wants to forbid this use of dynamic polymorphism outright.
> I think this is unacceptable, so in that case, it seems we have no
> choice but to start a formal process for resolving contentious
> decisions.


If this ends up being the case, then you *must* revert the patch until the
matter can be solved.

But as I said before, I would have reverted it a long time ago.

(I would still ask people to _please_ be good citizens and allow us to
> make upstream progress in AMDGPU as we usually do while this is
> happening -- I explain my reasoning a bit more below -- but I'd accept
> it based on the rules that are in effect today. Invoking the formal
> process should give all participants the confidence that the question
> doesn't just end up dropped on the floor, and that the in-tree status
> of the code wouldn't implicitly favor either side of the discussion.)
>

The AMD backend doesn't trump a high-level CFG design decision that affects
*all* back-ends, front-ends and middle-ends.

If you progress your AMD work on your current assumption and it turns out
people decide against it you will have to revert *all* of it, which is a
lot more substantial (and a potentially dangerous merge) than just this CFG
change.

I'd also strongly advise people reviewing the remaining work from approving
the patches until this matter can be resolved. This is not a trivial issue
and can have further consequences than just a simple revert.

And please, do not assume what being a good citizens is. We can all be good
citizens and still overwhelmingly disagree with each other, as long as we
keep it civil.

I see no evidence of lack of civility from either David or Mehdi. On the
contrary, they're being extremely kind and patient.

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


More information about the llvm-dev mailing list