[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