[llvm-dev] The undef story
Peter Lawrence via llvm-dev
llvm-dev at lists.llvm.org
Wed Jun 28 21:46:48 PDT 2017
I am not a “politically correct” person, never have been, never will be.
If you are waiting for me to make a politically incorrect statement so you can jump
on it, let me assure you that you will never be disappointed.
But if that’s all you do then you and llvm lose out. If you want to actually help
llvm move forward then you should judge what I say based on its merit, not on its
The thing I will agree with you about is that people on this list are well intentioned.
But I still don’t believe my description of “poison” has ever been discussed before,
you were will intentioned in saying it has, but there is no reason to believe it has,
because every time I dig deeper into these issues I run into mis-conceptions and
mis-information. Faulty analysis based on faulty assumptions. Every time. If I sound
hyperbolic it is because I have gotten frustrated from continually running into this.
And before you claim that I have insulted Dan, you might want to get his
opinion on the subject. My bet is he will react by saying “why didn’t I think
of that”, but in spite of my trying to contact him I have gotten no response.
Perhaps you will have better luck.
Finally, regarding John, when I pushed on the function-inlining example,
rather than responding to it he lashed out at me. That is unprofessional.
I said nothing about it at the time because I try to refrain from meta-discussions.
But it is another reason why I sound so hyperbolic.
Now, getting back to technical, I’m waiting for some C source code examples
showing how "Current transformations made by LLVM require [posion]”
> On Jun 28, 2017, at 6:47 PM, Chandler Carruth <chandlerc at gmail.com> wrote:
> On Wed, Jun 28, 2017 at 3:33 PM Peter Lawrence <peterl95124 at sbcglobal.net <mailto:peterl95124 at sbcglobal.net>> wrote:
> where we disagree is in whether the current project is moving the issue
> forward. It is not. It is making the compiler more complex for no additional value.
> I mean, I also disagree with your analysis of where we disagree, and what is happening, but I don't think that matters much or will convince you of anything.
> The current project perpetuates the myth that “poison” is somehow required.
> No one thinks it is required at a theoretical level. Current transformations made by LLVM require it. We could always disable those transformations. The current project is attempting to see if there is a pragmatic set of transformations we can keep with a better definition.
> It isn’t, and when I show proof of that you reply with “its in bug reports, etc”,
> that’s BS and you know it, this hasn’t been explored.
> I'm sorry that I didn't have readily available citations in the other thread. If you can show what searches you have done that didn't find any results, I'm happy to try and help find them. But the way you say this doesn't come across as assuming good faith on the part of myself and others in these discussions. Within the LLVM community, please always assume good faith and don't accuse people of "BS".
> Dan created “poison” on a whim, and people picked up on it too
> without question. We’ve been stuck with this self-inflicted wound ever since, and it is
> time to heal it.
> The way you have described this comes across as both hyperbolic and insulting to specific individuals.
> This kind of behavior and rhetoric is not acceptable in the LLVM community, and multiple people have asked you to change tone and avoid this behavior. Bluntly, stop.
> John and I do not have a technical disagreement, John is having an emotional
> reaction to the fact that he doesn’t have an answer to the function-inlining question.
> This is yet another personal attack in your email.
> After talking to several people involved in these threads, I think that whatever technical points you are trying to make have been completely lost due to the repeated pattern of apparent hostility. Your emails are perceived as insulting and attacking people which is not an appropriate or professional way to engage in a technical discussion here.
> The attitude and approach you are taking on the list is completely incompatible with this community and project.
> I still encourage you to modify LLVM and implement your approach. It is open source and easy to fork on GitHub. However, please don't continue sending emails to LLVM lists until you can do so without repeating this behavior.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev