[llvm-dev] amount of camelCase refactoring causing some downstream overhead

Nicolai Hähnle via llvm-dev
Wed, 19 Feb 2020 03:07:52 -0000

On Wed, Feb 19, 2020 at 3:22 AM David Blaikie via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> I think the somewhat unspoken change in LLVM social conventions (&
somewhat policy, I think it's written down in some places) is the "keep
patches as small as practically possible" - grouping unrelated renamings
would be something I'd usually (without concern for downstream consumers)
push back against for all the usual reasons: easier to review, easier to revert
strategically if something goes wrong, etc.
>
> What I'm not clear on is why one big rename patch is easier for a
downstream consumer than two smaller renames - I haven't fully understood
the nature of this particular downstream consumer's approach makes this
interesting.

The question that really matters is whether the rename is fully
automatic or not. If the rename is done by an automatic script (e.g.
clang-tidy based), then the same script can be run "downstream" ahead
of merges to avoid virtually all of the conflicts. And if the rename
is performed by an automatic script, it seems like it'd actually be
simpler for everybody to do it in one big patch, or perhaps one C++
namespace at a time.

The biggest remaining problem in this scenario is with *users* of LLVM
that call into the C++ API and aim to maintain source-compatibility
against multiple versions of LLVM. I currently cannot see how that
would work.

Full disclaimer about where I'm coming from: We (AMD's graphics
compiler) are affected by the rename on two counts:

1) In llvm-project itself, we're upstream (AMDGPU backend), but we do
have fairly long-lived internal branches for development against
unreleased hardware that are still kept up-to-date with automatic
merges multiple times per day.

2) Outside of llvm-project, the compiler frontend (llpc, which is also
open-source) also tracks llvm-project master closely and calls into
the C++ interface, so would also be affected.

(We currently don't attempt to maintain compatibility with multiple
versions of LLVM, though it's something that I'd like us to do at some
point.)

Cheers,
Nicolai



>
> - Dave
>
>>
>>
>> -eric
>>
>> On Tue, Feb 18, 2020 at 4:05 PM Philip Reames via llvm-dev <llvm-dev
at lists.llvm.org> wrote:
>>>
>>> Valentin,
>>>
>>> You are proposing to change existing policy.  Current policy is
that we don't consider downstream *at all*.  Your proposal may seem
reasonable - it may even *be* reasonable - but it is definitely a change from
historical practice and must be considered as such.
>>>
>>> Philip
>>>
>>> On 2/18/20 3:03 PM, Valentin Churavy wrote:
>>>
>>> I don't think anyone is arguing to change longstanding policy.
From a downstream perspective many small renaming changes do increase overhead
for us.
>>>
>>> One thing that happens to downstream projects is that they support
more than one LLVM version, we (JuliaLang) currently try to support latest
stable + master.
>>>
>>> So for me the question is more, are renaming changes worth
downstream projects not being able to test and provide feedback to upstream?
One way of mitigating that is to consciously schedule them just before a release
and do them all in short succession.
>>>
>>> -V
>>>
>>>
>>> On Tue, Feb 18, 2020, 17:00 Philip Reames via llvm-dev <llvm-dev
at lists.llvm.org> wrote:
>>>>
>>>> As others have said, our long standing policy has been that
downstream
>>>> projects must fend for themselves.  We're certainly not
going to reverse
>>>> that policy without careful discussion of the tradeoffs.
>>>>
>>>> I'm personally of the opinion that there could be a middle
ground which
>>>> allows upstream to move quickly while reducing headache for
downstream
>>>> projects.  Given I wear both hats, I know I'd certainly
appreciate such
>>>> a state.  However, it's important to state that such
decisions would
>>>> need to be carefully considered and would require some very
careful
>>>> drafting of proposal to balance the competing interests at
hand.
>>>>
>>>> If anyone is curious, I'm happy to share some ideas offline
on what
>>>> starting points might be, but I have neither the time nor the
interest
>>>> to drive such a conversion on list.
>>>>
>>>> Philip
>>>>
>>>> On 2/18/20 1:37 AM, Ties Stuij via llvm-dev wrote:
>>>> > During that variable renaming debate, there was a
discussion about discussion about doing things all at once, piecemeal or not at
all. An issue that wasn't really resolved I think. I had the impression that
the efforts fizzled out a bit, and I thought this renaming was maybe related to
that, but I'm neutral on if we should do variable renaming.
>>>> >
>>>> > All I'm asking as a kindness if we could be kind on
poor downstream maintainers not on the issue of variable renaming at large, but
on the micro level of not pushing 5/6 patches of this kind covering closely
related functionality in two days but collating them in 1. I don't think
that would slow down development, and I wanted to highlight the issue, as people
might not be aware that they could save some pain in a simple way. Especially if
indeed there is going to be a big renaming push and this would be a continuous
thing.
>>>> >
>>>> > Cheers,
>>>> > /Ties
>>>> >
>>>> > ________________________________________
>>>> > From: Michael Kruse <llvmdev at meinersbur.de>
>>>> > Sent: 17 February 2020 21:16
>>>> > To: Ties Stuij
>>>> > Cc: llvm-dev
>>>> > Subject: Re: [llvm-dev] amount of camelCase refactoring
causing some downstream overhead
>>>> >
>>>> > My understanding is that LLVM's general policy is to
not let
>>>> > downstream slow down upstream development. The C++ API
explicitly
>>>> > unstable.
>>>> >
>>>> > Note that we are even considering renaming variables
globally:
>>>> >
https://lists.llvm.org/pipermail/llvm-dev/2019-September/134921.html
>>>> >
>>>> > Michael
>>>> >
>>>> > Am Mo., 17. Feb. 2020 um 06:04 Uhr schrieb Ties Stuij via
llvm-dev
>>>> > <llvm-dev at lists.llvm.org>:
>>>> >> Hi there,
>>>> >>
>>>> >> At the end of last week we saw a number of commits go
in that were camelCasing batches of MCStreamer::Emit* and AsmPrinter::Emit*
functions.
>>>> >>
>>>> >> For example:
>>>> >> -
https://reviews.llvm.org/rG549b436beb4129854e729a3e1398f03429149691
>>>> >> -
https://reviews.llvm.org/rGa55daa146166353236aa528546397226bee9363b
>>>> >> -
https://reviews.llvm.org/rG0bc77a0f0d1606520c7ad0ea72c434661786a956
>>>> >>
>>>> >> Unfortunately all these individual commits trigger the
same merge conflicts over and over again with our downstream repo, which takes
us some manual intervention every time.
>>>> >>
>>>> >> I understand uniformity is a nice to have, but:
>>>> >> 1 - is it worth it to do this work right now? I can
remember the casing debate a few months back, which seems unrelated to this work
which seems manual, but I'm unsure of the outcome.
>>>> >> 2 - If this work should be done, it would be nice if
all of the work is done in one batch, to save us some of the downstream
overhead.
>>>> >>
>>>> >> Thanks
>>>> >> /Ties
>>>> >> _______________________________________________
>>>> >> LLVM Developers mailing list
>>>> >> llvm-dev at lists.llvm.org
>>>> >>
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>> > _______________________________________________
>>>> > LLVM Developers mailing list
>>>> > llvm-dev at lists.llvm.org
>>>> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> llvm-dev at lists.llvm.org
>>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev



--
Lerne, wie die Welt wirklich ist,
aber vergiss niemals, wie sie sein sollte.