[llvm-dev] The undef story

[Chandler Carruth via llvm-dev]

On Wed, Jun 28, 2017 at 9:39 AM Peter Lawrence <peterl95124 at sbcglobal.net>
wrote:

>
>
> Part I.
>
> The original LangRef appeared to be “nice and pretty”
> and originally ‘undef’ did not seem to stick out.
>
> Then  evidence came to light in the form of bug reports, and
> in the form of Dan Gohman’s email “the nsw story”, that all
> was not good for ‘undef’ [1,2].
>
> A proposal was made based on that evidence.
> A presentation was made at an llvm gathering.
> A paper was written. The proposal has even been
> implemented and tested.
>
> The IR might not be so “nice and pretty” anymore,
> but at least all the known bugs could be closed.
> I think everyone agreed that the case could be closed
> based on the evidence at hand.
>
> However new evidence has come to light,
> the function-inlining example for one,
> which the proposal does not address.
>
> This means the case must be re-opened.
>

Peter,

People have been continuing to work on these issues for years. This is not
new, and and it is not only now being reopened.


Unfortunately, at this point I think you are repeating well known and well
understood information in email after email. I don't think that is a
productive way to discuss this. However, I don't want to dissuade you from
contributing to the project. But I don't think new emails on this subject
will not be a good use of anyone's time.

Instead, someone needs to go do the very hard work of building, testing,
and understanding solutions to some of these problems. In fact, a few
others are already doing exactly this.

I understand you disagree with the approach others are taking, and that is
perfectly fine, even good! You have explained your concern, and there
remains a technical disagreement. This is OK. Repeating your position won't
really help move forward.

Contributing technical perspectives (especially different ones!) is always
valuable, and I don't want to ever discourage it. But when there remains a
strong technical disagreement, we have to find some way to make
progress.Typically, LLVM lends weight towards those who have the most
significant contributions to LLVM in the area *and* are actually doing the
work to realize a path forward. This doesn't make them any more "right" or
their opinions "better". It is just about having a path forward.

But this should also show you how to make progress. Continuing to debate in
email probably won't help as you're relatively new to the LLVM project.
Instead, write the code, get the data and benchmark results to support your
position and approach, and come back to us. I think you will have to do the
engineering work of building the solution you want (and others disagree
with) and showing why it is objectively better.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170628/e7f49162/attachment.html>