[llvm-dev] [RFC] AAP Backend
Renato Golin via llvm-dev
llvm-dev at lists.llvm.org
Sat Aug 27 06:28:40 PDT 2016
On 27 August 2016 at 04:51, James Y Knight <jyknight at google.com> wrote:
> This would be a first for an LLVM backend AFAIK -- all the other backends
> have an expected direct user-base, while AAP seems basically artificial.
Hi James,
That is a very good point.
> However, it seems to me that AAP probably deserves to be an exception to
> that general rule (at least unless/until LLVM gains "real" backends upstream
> with similar characteristics) due to its goals and design of being a
> stand-in for an entire category of real targets with real users which are
> under-represented by existing LLVM backends.
This is more or less my view, yes.
> Which is all to say, I think it would be a good decision to accept AAP, but
> only if it's done by explicitly and knowingly exempting it from an
> acceptance criteria that should be imposed on all other backends.
That criteria is not encoded in our policy, so strictly speaking,
cannot be used as an "acceptance criterium" to refuse AAP.
We can change our policy, and it seems there are enough propositions
to do so. But as it stands, it would be unfair to make it as hard as
our other criteria.
If that specific topic (which I agree with you *is* pertinent), was
already in the policy, I would still request an exception, as you did,
pretty much for the same reasons.
I'm an optimist. I trust people's enthusiasm, more than I trust
people's speech and roadmaps. I think the LLVM community is more
enthusiastic than others I've been, even though it's full of companies
and roadmaps, and that makes it a wonderful place to work. I don't
want to lose that.
I think that accepting Lanai, BPF, RISC-V, WebAssembly and AAP are
reflections of our enthusiasm taking over the fear of potential
maintenance, and that's a good thing. We also have shown that we have
the mechanisms and will to deprecate bit-rotten code, and that has
worked remarkably well in the past. So, I'd rather try and fail than
not to try at all, and miss the opportunity to further enrich people's
experiences.
Thanks for your comments, they were enlightening.
cheers,
-renato
More information about the llvm-dev
mailing list