[LLVMdev] (no subject)

Marshall Spight marshall.spight at gmail.com
Thu May 5 14:26:19 PDT 2005


>>     In other words, abandoning overflow detection makes the
>>     duplication of types redundant, while requiring it would be a
>>     great burden on CPUs that don't have overflow exception hardware.
>
>Yes, you're right. This has been a desired change for quite some time
>now. Unfortunately, its a huge impact to nearly every part of LLVM. We
>will probably do it around the 2.0 time frame when we can afford to
>break bytecode compatibility and generally clean up a lot of other
>things as well.

Uh, does this mean you're contemplating getting rid of llvm's ability
to detect an interger overflow? So if I add, say, two 32-bit signed
ints with values 2000000000 and 2000000000 I'm going to get
-294967296 and have no way to know that something bad happened?

That would make me sad. I'm not entirely sure I see the rationale;
isn't it the case that only languages that care to support such
overflow detection would pay the runtime cost?

This seems like more of the circularity of the tyranny of C. Hardware
certainly *could* support this transparently; C doesn't care, though; so
hardware doesn't need to support overflow detection.


Marshall




More information about the llvm-dev mailing list