[LLVMdev] Preferring to use GCC instead of LLVM - ENOUGH
Tanya M. Lattner
tonic at nondot.org
Tue May 13 12:08:05 PDT 2008
OK, this thread is getting nasty and off topic. If you continue in this
manner, I will have to start banning people from the list. The LLVM
mailing list is not a place for insults or attacking other people.
Please, let this thread die.
-Tanya
On Tue, 13 May 2008, kr512 wrote:
>
> Jon Harrop wrote:
>> So LLVM has relatively poor support for Windows, no direct
>> support for DLL generation and the exact opposite of your
>> performance requirements.
>
> I see. This news is disappointing to me.
>
>> I appreciate that you have customer demands but those
>> demands are very unusual (and, frankly, absurd!) but you
>> must try to meet them regardless.
>
> Very unusual? Absurd? Who the what?! I feel like we are
> talking about completely different topics. I feel like you
> have just stated that sex is unpopular and very unusual.
>
> I don't see how you can possibly say it is very unusual.
> Everyone is doing it. You are doing it too. You are doing
> it and yet you are saying it is absurd. If it is absurd,
> why are you doing it?!
>
> It is an indisputable fact that the majority of software is
> fully compiled to native code files BEFORE being launched,
> not during. If anything is unusual, it is JIT that is
> unusual. JIT is the behavior in the minority -- there is
> no doubting that fact. JIT is the unusual one.
>
> I don't want JIT. At this very moment you are almost
> certainly running non-JIT programs on your computer. And
> yet you say that it is very unusual and absurd! What the...
> ?!
>
> Why is it absurd? You didn't state ANY reasons why it is
> absurd. There is no point in saying that something is
> absurd if you don't provide any reasons to support your
> opinion.
>
> If anything is absurd, it is JIT that is absurd. There is
> hardly any reason to bother with the added complexity and
> reduced performance of JIT -- it is simpler and easier and
> better performance to compile the program at some point
> BEFORE launching rather than DURING execution, and to store
> that native code on disk.
>
> OK yes in some situations JIT does make sense, but in most
> situations it clearly does NOT, and that is why JIT is NOT
> used in MOST situations. Because in most situations, using
> JIT would be absurd!
>
> MY GOD MAN!! For chrissakes, how can you say that sex is
> unpopular?!?!
>
> JIT is the one that is unusual and absurd, not sex, and
> there is absolutely no disputing the fact that the majority
> of programs are fully compiled to native code files at some
> point BEFORE being launched. Trying to convert the program
> to native code DURING execution is an absurd
> over-complicated unnecessary strategy except in some special
> situations.
>
> Sorry for being a bit repetitive but you have just stated
> that sex is unpopular and I don't know how else to get the
> message across that actually it is very popular, and how on
> earth can you not know this?!
>
>> Nobody here cares about providing that functionality
>> because nobody else wants it.
>
> If nobody wants it, then why is it so very popular and
> commonly used? If people don't seem to care about it, it is
> because they are already getting it elsewhere -- from GCC,
> MSVS, etc.
>
> It is like when you have lots of sex, you aren't much
> interested in getting more sex from others. You are not
> uninterested in sex because sex is unwanted, rather you are
> uninterested because you are already getting lots of it.
> Sheesh.
>
> And Jon, for your own sake, please let me assure you, I
> don't know what your parents or friends have been telling
> you, but it is very very common, and not at all unusual.
> Loads of people are doing it apparently without you having
> knowledge of it. Try it, and I think you will see why
> millions of people like it and don't think it absurd.
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
More information about the llvm-dev
mailing list