Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.compilers > #2205 > unrolled thread
| Started by | David Brown <david.brown@hesbynett.no> |
|---|---|
| First post | 2019-04-25 21:58 +0200 |
| Last post | 2019-05-07 16:38 +0200 |
| Articles | 7 on this page of 87 — 14 participants |
Back to article view | Back to comp.compilers
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: Optimization techniques David Brown <david.brown@hesbynett.no> - 2019-04-25 21:58 +0200
Re: Optimization techniques Kaz Kylheku <847-115-0292@kylheku.com> - 2019-04-26 00:18 +0000
Re: Optimization techniques David Brown <david.brown@hesbynett.no> - 2019-04-28 23:49 +0200
Re: Optimization techniques and undefined behavior Bart <bc@freeuk.com> - 2019-04-29 00:31 +0100
Re: Optimization techniques and undefined behavior David Brown <david.brown@hesbynett.no> - 2019-04-29 17:08 +0200
Re: Optimization techniques and undefined behavior Christian Gollwitzer <auriocus@gmx.de> - 2019-04-29 18:10 +0200
Re: Optimization techniques and undefined behavior David Brown <david.brown@hesbynett.no> - 2019-04-30 14:46 +0200
Re: Optimization techniques and undefined behavior Bart <bc@freeuk.com> - 2019-05-01 13:53 +0100
Re: Optimization techniques and undefined behavior Andy Walker <anw@cuboid.co.uk> - 2019-05-02 11:29 +0100
Re: Optimization techniques and undefined behavior Bart <bc@freeuk.com> - 2019-05-03 00:48 +0100
Re: Optimization techniques and undefined behavior Martin Ward <martin@gkc.org.uk> - 2019-05-03 10:52 +0100
Re: Optimization techniques and undefined behavior George Neuner <gneuner2@comcast.net> - 2019-05-04 17:44 -0400
Re: Bounds checking, Optimization techniques and undefined behavior George Neuner <gneuner2@comcast.net> - 2019-05-05 17:10 -0400
Re: Optimization techniques and undefined behavior David Brown <david.brown@hesbynett.no> - 2019-05-06 08:14 +0200
Re: Optimization techniques and undefined behavior Gene Wirchenko <genew@telus.net> - 2019-05-11 22:25 -0700
Re: not a lot of memory, was Optimization techniques and undefined behavior Bart <bc@freeuk.com> - 2019-05-03 12:45 +0100
Re: Optimization techniques and undefined behavior Andy Walker <anw@cuboid.co.uk> - 2019-05-03 13:29 +0100
Re: Optimization techniques and undefined behavior Bart <bc@freeuk.com> - 2019-05-03 23:10 +0100
Re: Optimization techniques and undefined behavior Andy Walker <anw@cuboid.co.uk> - 2019-05-04 10:45 +0100
Re: Bounds checking, Optimization techniques and undefined behavior Bart <bc@freeuk.com> - 2019-05-05 11:14 +0100
Re: Bounds checking, Optimization techniques and undefined behavior Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2019-05-05 20:44 +0200
Re: Bounds checking, Optimization techniques and undefined behavior Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2019-05-06 10:15 +0200
Re: Bounds checking, Optimization techniques and undefined behavior David Brown <david.brown@hesbynett.no> - 2019-05-07 11:04 +0200
Re: Bounds checking, Optimization techniques and undefined behavior "Nuno Lopes" <nuno.lopes@ist.utl.pt> - 2019-05-07 22:38 +0100
Re: Bounds checking, Optimization techniques and undefined behavior Bart <bc@freeuk.com> - 2019-05-08 01:14 +0100
Re: Bounds checking, Optimization techniques and undefined behavior David Brown <david.brown@hesbynett.no> - 2019-05-08 09:55 +0200
Re: Bounds checking, Optimization techniques and undefined behavior "Derek M. Jones" <derek@_NOSPAM_knosof.co.uk> - 2019-05-08 19:08 +0100
Re: Bounds checking, Optimization techniques and undefined behavior Andy Walker <anw@cuboid.co.uk> - 2019-05-08 01:42 +0100
Re: Bounds checking, Optimization techniques and undefined behavior David Brown <david.brown@hesbynett.no> - 2019-05-08 10:16 +0200
Re: Bounds checking, Optimization techniques and undefined behavior Bart <bc@freeuk.com> - 2019-05-09 01:15 +0100
Re: Bounds checking, Optimization techniques and undefined behavior David Brown <david.brown@hesbynett.no> - 2019-05-09 21:56 +0200
Re: Bounds checking, Optimization techniques and undefined behavior David Brown <david.brown@hesbynett.no> - 2019-05-08 10:03 +0200
Re: Bounds checking, Optimization techniques and undefined behavior David Brown <david.brown@hesbynett.no> - 2019-05-09 09:19 +0200
Re: Bounds checking, Optimization techniques and undefined behavior Kaz Kylheku <847-115-0292@kylheku.com> - 2019-05-10 03:38 +0000
Re: Bounds checking, Optimization techniques and undefined behavior Bart <bc@freeuk.com> - 2019-05-08 14:37 +0100
Re: Bounds checking, Optimization techniques and undefined behavior Christopher F Clark <christopher.f.clark@compiler-resources.com> - 2019-05-06 05:05 -0400
Re: Bounds checking, Optimization techniques and undefined behavior George Neuner <gneuner2@comcast.net> - 2019-05-05 17:38 -0400
Re: Bounds checking, Optimization techniques and undefined behavior Bart <bc@freeuk.com> - 2019-05-06 13:07 +0100
Re: Bounds checking, Optimization techniques and undefined behavior David Brown <david.brown@hesbynett.no> - 2019-05-07 14:01 +0200
Re: Bounds checking, Optimization techniques and undefined behavior Andy Walker <anw@cuboid.co.uk> - 2019-05-06 01:15 +0100
Re: Bounds checking, Optimization techniques and undefined behavior Andy Walker <anw@cuboid.co.uk> - 2019-05-06 14:40 +0100
Re: Bounds checking, Optimization techniques and undefined behavior David Brown <david.brown@hesbynett.no> - 2019-05-07 15:05 +0200
Re: Bounds checking, Optimization techniques and undefined behavior David Brown <david.brown@hesbynett.no> - 2019-05-08 10:18 +0200
Re: Bounds checking, Optimization techniques and undefined behavior Jan Ziak <0xe2.0x9a.0x9b@gmail.com> - 2019-05-06 05:39 -0700
Re: Bounds checking, Optimization techniques and undefined behavior David Brown <david.brown@hesbynett.no> - 2019-05-07 15:42 +0200
Re: Bounds checking, Optimization techniques and undefined behavior David Brown <david.brown@hesbynett.no> - 2019-05-06 16:32 +0200
Re: Optimization techniques and undefined behavior George Neuner <gneuner2@comcast.net> - 2019-05-04 17:59 -0400
Re: Optimization techniques and undefined behavior David Brown <david.brown@hesbynett.no> - 2019-05-02 16:51 +0200
Re: Optimization techniques and undefined behavior Bart <bc@freeuk.com> - 2019-05-02 20:04 +0100
Re: Optimization techniques and undefined behavior David Brown <david.brown@hesbynett.no> - 2019-05-03 17:23 +0200
Re: Optimization techniques and undefined behavior Bart <bc@freeuk.com> - 2019-05-03 21:10 +0100
Re: Optimization techniques and undefined behavior Martin Ward <martin@gkc.org.uk> - 2019-05-06 13:25 +0100
Re: Optimization techniques and undefined behavior "Derek M. Jones" <derek@_NOSPAM_knosof.co.uk> - 2019-05-06 16:32 +0100
Re: Optimization techniques and undefined behavior David Brown <david.brown@hesbynett.no> - 2019-05-07 16:03 +0200
Re: Optimization techniques and undefined behavior Martin Ward <martin@gkc.org.uk> - 2019-05-08 13:16 +0100
Re: Optimization techniques and undefined behavior George Neuner <gneuner2@comcast.net> - 2019-05-08 15:13 -0400
Re: Optimization techniques and undefined behavior "Robin Vowels" <robin51@dodo.com.au> - 2019-05-07 01:22 +1000
Re: Optimization techniques and undefined behavior David Brown <david.brown@hesbynett.no> - 2019-05-07 16:05 +0200
Re: Optimization techniques and undefined behavior Christian Gollwitzer <auriocus@gmx.de> - 2019-05-02 22:22 +0200
Re: Optimization techniques and undefined behavior Bart <bc@freeuk.com> - 2019-04-29 18:15 +0100
Re: Optimization techniques and undefined behavior David Brown <david.brown@hesbynett.no> - 2019-04-30 15:48 +0200
Re: Optimization techniques and undefined behavior Bart <bc@freeuk.com> - 2019-05-01 12:40 +0100
Re: Optimization techniques and undefined behavior David Brown <david.brown@hesbynett.no> - 2019-05-02 17:27 +0200
Re: Optimization techniques and undefined behavior Bart <bc@freeuk.com> - 2019-05-02 18:59 +0100
Re: Optimization techniques and undefined behavior David Brown <david.brown@hesbynett.no> - 2019-05-07 16:16 +0200
Re: Optimization techniques and undefined behavior Martin Ward <martin@gkc.org.uk> - 2019-05-02 14:54 +0100
Re: Optimization techniques and runtime checks Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2019-04-29 22:36 +0200
Re: Optimization techniques and runtime checks David Brown <david.brown@hesbynett.no> - 2019-05-07 16:29 +0200
Re: Optimization techniques and runtime checks Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2019-05-08 02:27 +0200
Re: Optimization techniques and runtime checks David Brown <david.brown@hesbynett.no> - 2019-05-08 10:31 +0200
Re: Optimization techniques and runtime checks Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2019-05-08 22:50 +0200
Re: Optimization techniques and runtime checks "Robin Vowels" <robin51@dodo.com.au> - 2019-05-11 19:26 +1000
Re: Optimization techniques and runtime checks Gene Wirchenko <genew@telus.net> - 2019-05-11 22:43 -0700
Re: Optimization techniques and runtime checks David Brown <david.brown@hesbynett.no> - 2019-05-12 20:17 +0200
Re: Optimization techniques and runtime checks Bart <bc@freeuk.com> - 2019-05-08 14:58 +0100
Re: Optimization techniques and runtime checks David Brown <david.brown@hesbynett.no> - 2019-05-08 23:02 +0200
Re: Optimization techniques and runtime checks Bart <bc@freeuk.com> - 2019-05-09 18:28 +0100
Re: Optimization techniques and runtime checks David Brown <david.brown@hesbynett.no> - 2019-05-09 22:07 +0200
Re: Optimization techniques Gene Wirchenko <genew@telus.net> - 2019-04-30 18:24 -0700
Re: Optimization techniques David Brown <david.brown@hesbynett.no> - 2019-05-01 09:20 +0200
Re: Optimization techniques Kaz Kylheku <847-115-0292@kylheku.com> - 2019-05-02 17:40 +0000
Re: Optimization techniques and error detection Gene Wirchenko <genew@telus.net> - 2019-05-03 10:16 -0700
Re: Optimization techniques "Robin Vowels" <robin51@dodo.com.au> - 2019-05-07 01:42 +1000
Re: Optimization techniques Kaz Kylheku <847-115-0292@kylheku.com> - 2019-04-26 02:26 +0000
Re: Optimization techniques and undefined behavior David Brown <david.brown@hesbynett.no> - 2019-04-29 00:12 +0200
Re: Optimization techniques and undefined behavior Kaz Kylheku <847-115-0292@kylheku.com> - 2019-05-02 17:18 +0000
Re: Optimization techniques and undefined behavior David Brown <david.brown@hesbynett.no> - 2019-05-07 16:38 +0200
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
| From | Kaz Kylheku <847-115-0292@kylheku.com> |
|---|---|
| Date | 2019-05-02 17:40 +0000 |
| Message-ID | <19-05-011@comp.compilers> |
| In reply to | #2238 |
On 2019-05-01, David Brown <david.brown@hesbynett.no> wrote: > On 01/05/2019 03:24, Gene Wirchenko wrote: >> On Sun, 28 Apr 2019 23:49:53 +0200, David Brown >> <david.brown@hesbynett.no> wrote: >> >> [snip] >> >>> If you are writing your code in a "C with the extra feature of having >>> defined behaviour on signed integer overflow", and only compile it with >>> suitable compilers (or compiler flags), then that's okay. But don't >>> call it correct C code and blame compilers for your own mistakes or >>> unwarranted assumptions. >> >> I would like to see it as part of the language. I *know* that I >> want to have an error be thrown at run-time if an error can be >> detected. (It is not an unwarranted assumption.) It is not as if >> detecting signed integer overflow is a difficult thing on, for >> example, System/370, which also dates from 1970. > > Detecting signed overflow at run-time can be a significant cost. It > ruins expression manipulation, optimisation, and simplification - much If we detect signed overflow and treat it as an error condition, then we can optimize algebraically just as before, on the assumption that overflow doesn't happen. If it does happen, we have a predictable handling, rather than "undefined behavior". We just don't constrain the exact situations when it must happen. I.e. as usual, optimizations are permitted that can eliminate instances of overflow that would otherwise happen if the specified arithmetic is followed, optimizations that can introduce overflow aren't allowed. > more than making signed overflow be two's complement. Even compared to > a dumb translation compilation of expressions, it nearly doubles the > size of the code on many processors as you have to follow each > arithmetic instruction with a "jump if overflow". Some can also set a processor flag which can be tested after a batch of operations, rather than each one. That is reasonably cheap on those processors because the flag is there anyway; you just have to peek at it once in a while. Some RISCs can write overflow info into an additional output register, rather than a global flag word, IIRC. We often care about whether anything at all overflowed in a complex expression, without caring about which specific operation on which operands. The design issue then is how to indicate the granularity of overflow detection in the higher level language. A scoped construct suggests itself, the "owfl" operator: owfl(expr, alt) If anything inside expr overflows, then alt is evaluated, and taken as the result of the expression. Considerations have to be given to how this nests with itself, including through functions, and when/how does the overflow condition get cleared. (We don't want it so that once an overflow happens, every owfl subsequently executed defaults to its alt until the program terminates.) [FWIW the x86 series had an INTO instruction which interrupts if the overflow flag is on, but they took it out of 64 bit mode. You can still do a conditional jump or move. -John]
[toc] | [prev] | [next] | [standalone]
| From | Gene Wirchenko <genew@telus.net> |
|---|---|
| Date | 2019-05-03 10:16 -0700 |
| Subject | Re: Optimization techniques and error detection |
| Message-ID | <19-05-022@comp.compilers> |
| In reply to | #2238 |
On Wed, 1 May 2019 09:20:23 +0200, David Brown
<david.brown@hesbynett.no> wrote:
>On 01/05/2019 03:24, Gene Wirchenko wrote:
>> On Sun, 28 Apr 2019 23:49:53 +0200, David Brown
>> <david.brown@hesbynett.no> wrote:
>>
>> [snip]
>>
>>> If you are writing your code in a "C with the extra feature of having
>>> defined behaviour on signed integer overflow", and only compile it with
>>> suitable compilers (or compiler flags), then that's okay. But don't
>>> call it correct C code and blame compilers for your own mistakes or
>>> unwarranted assumptions.
>>
>> I would like to see it as part of the language. I *know* that I
>> want to have an error be thrown at run-time if an error can be
>> detected. (It is not an unwarranted assumption.) It is not as if
>> detecting signed integer overflow is a difficult thing on, for
>> example, System/370, which also dates from 1970.
>
>Detecting signed overflow at run-time can be a significant cost. It
Not detecting it can have a significant cost, too. Incorrect
results can cost.
> ...
>No, throwing an error on overflows is not hard - but it /is/ costly. It
>can be a marvellous tool during testing and debugging, and may be worth
>leaving active in some programs, but it has a price.
I do not deny it has a price, but I do not care about the price.
I want the correctness. Others have different priorities: fine, but I
want my priorities dealt with, too.
Sincerely,
Gene Wirchenko
[toc] | [prev] | [next] | [standalone]
| From | "Robin Vowels" <robin51@dodo.com.au> |
|---|---|
| Date | 2019-05-07 01:42 +1000 |
| Message-ID | <19-05-043@comp.compilers> |
| In reply to | #2238 |
From: "David Brown" <david.brown@hesbynett.no> > On 01/05/2019 03:24, Gene Wirchenko wrote: >> On Sun, 28 Apr 2019 23:49:53 +0200, David Brown >> <david.brown@hesbynett.no> wrote: >>> If you are writing your code in a "C with the extra feature of having >>> defined behaviour on signed integer overflow", and only compile it with >>> suitable compilers (or compiler flags), then that's okay. But don't >>> call it correct C code and blame compilers for your own mistakes or >>> unwarranted assumptions. >> >> I would like to see it as part of the language. I *know* that I >> want to have an error be thrown at run-time if an error can be >> detected. (It is not an unwarranted assumption.) It is not as if >> detecting signed integer overflow is a difficult thing on, for >> example, System/370, which also dates from 1970. Signed (and unsigned) overflow was around on the IBM 360 from 1965. > Detecting signed overflow at run-time can be a significant cost. Usually not. Even on humble micros, a Junp on overflow or an Interrupt on overflow is usually available. On the S/370 that was mentioned above, and the S/360 before it, and later machines in that family, an overflow is detected by hardware. Extra instructions are not required to detect the overflow. (They can be, if the user desires to process them him/herself.) > It > ruins expression manipulation, optimisation, and simplification - much > more than making signed overflow be two's complement. Even compared to > a dumb translation compilation of expressions, it nearly doubles the > size of the code on many processors as you have to follow each > arithmetic instruction with a "jump if overflow". A jump on overflow is usually a short instruction, less than the length of instruction(s) that generated the overflow. > (Some cpus have > "trapping" arithmetic instructions, but certainly not all.) On small > processors, this is all a heavy penalty on performance. On big > processors, simple instructions are often "free" while the cpu is > waiting for memory reads, but these sequences thrash your branch > prediction buffers. Again, on the S/370 et al already mentioned, no extra instrucions are required to test for overflow. Branch prediction is irrelevant in the event of an overflow. To proceed with the computation is pointless. > No, throwing an error on overflows is not hard - but it /is/ costly. It > can be a marvellous tool during testing and debugging, and may be worth > leaving active in some programs, but it has a price. The "price" of leaving in checks (active or otherwise) is small compared to the human time wasted in tracking down a bug in a program -- whether it is overflow or some other computational error. [IBM mainframes have integer overflow traps, but the Intel micros that most of use do not. There's an overflow flag but the only way to act on it is to put a conditional branch after each instruction that might overflow, which could make things a tad bulky and sluggish. Maybe that's worth it, but it's far from cheap. -John]
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <847-115-0292@kylheku.com> |
|---|---|
| Date | 2019-04-26 02:26 +0000 |
| Message-ID | <19-04-024@comp.compilers> |
| In reply to | #2205 |
On 2019-04-25, David Brown <david.brown@hesbynett.no> wrote: > It knows that "x * 2 / 2" is "x". It knows that "x + 1 > x" is true. Also, we could have it so that multiplication wraps, and yet in the same breath allow algebraic reductions like this anyway. Basically it can be so that, if overflow takes place in the abstract semantics of "x * 2 / 2", the result can be either the truncated version, or just x, if the algebraic reduction took place. Algebraic reductions that can change the result can be confined to evaluation regions similar to (perhaps tied to) sequence points, such that if we write: int y = x * 2; int z = y / 2; then the calculations are belabored; z is not reduced to x. Anyway, anyone who wants "x * 2 / 2" to be reduced to "x" through layers of macrology can always use a more sophisticated macro processor. Parse it, build a tree, and do the optimization in the preprocessor. C should serve as a stable "higher level assembly" target for that sort of thing. [I take your point but there's an awful lot of macros doing data structure stuff that frequently give you this kind of code. -John]
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-04-29 00:12 +0200 |
| Subject | Re: Optimization techniques and undefined behavior |
| Message-ID | <19-04-038@comp.compilers> |
| In reply to | #2208 |
On 26/04/2019 04:26, Kaz Kylheku wrote: > On 2019-04-25, David Brown <david.brown@hesbynett.no> wrote: >> It knows that "x * 2 / 2" is "x". It knows that "x + 1 > x" is true. > > Also, we could have it so that multiplication wraps, and yet in the same > breath allow algebraic reductions like this anyway. > > Basically it can be so that, if overflow takes place in the abstract > semantics of "x * 2 / 2", the result can be either the truncated > version, or just x, if the algebraic reduction took place. > I am afraid I don't understand you here. Are you saying that you could define the language's arithmetic so that, given "x * 2 / 2", the compiler could return /either/ "x" or the result you would get from wrapped overflow calculations? You are defining two possible "correct" answers? > Algebraic reductions that can change the result can be confined > to evaluation regions similar to (perhaps tied to) sequence points, > such that if we write: > > int y = x * 2; > int z = y / 2; > > then the calculations are belabored; z is not reduced to x. > Note that in C, as defined by the standards (whether you agree with them or not), sequence points do not cause any such effects. z can be reduced to x. > Anyway, anyone who wants "x * 2 / 2" to be reduced to "x" through layers > of macrology can always use a more sophisticated macro processor. Parse > it, build a tree, and do the optimization in the preprocessor. > I find the C preprocessor to be quite sophisticated. And I find compiler optimisation, such as inline and constant propagation, to be even more sophisticated. Sometimes I use additional pre-processing or code generation for specialist use, but I am happy not to need it for this kind of thing. > C should serve as a stable "higher level assembly" target for that sort > of thing. No, C should serve as a stable "higher level language" - not an assembly. If you want to have a "higher level assembly", then you can make that from C - typically the usage of unsigned types rather than signed types will give you most of what you want here. A liberal sprinkling of "volatile" is also useful in such use-cases. And, if you really want to, it's not hard to write something like: #ifdef __GNUC__ #pragma GCC optimize -fwrapv #endif
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <847-115-0292@kylheku.com> |
|---|---|
| Date | 2019-05-02 17:18 +0000 |
| Subject | Re: Optimization techniques and undefined behavior |
| Message-ID | <19-05-010@comp.compilers> |
| In reply to | #2222 |
On 2019-04-28, David Brown <david.brown@hesbynett.no> wrote:
> On 26/04/2019 04:26, Kaz Kylheku wrote:
>> On 2019-04-25, David Brown <david.brown@hesbynett.no> wrote:
>>> It knows that "x * 2 / 2" is "x". It knows that "x + 1 > x" is true.
>>
>> Also, we could have it so that multiplication wraps, and yet in the same
>> breath allow algebraic reductions like this anyway.
>>
>> Basically it can be so that, if overflow takes place in the abstract
>> semantics of "x * 2 / 2", the result can be either the truncated
>> version, or just x, if the algebraic reduction took place.
>>
>
> I am afraid I don't understand you here. Are you saying that you could
> define the language's arithmetic so that, given "x * 2 / 2", the
> compiler could return /either/ "x" or the result you would get from
> wrapped overflow calculations? You are defining two possible "correct"
> answers?
I'm fairly comfortable with this, because it maps to the familiar ISO C
concept of "unspecified behavior".
For instance, this program can produce one of the results -12, -6, -2
or 4, based on which of the six permutations over the order in which the
three functions are called.
#include <stdio.h>
int x = 1;
int add2(void)
{
x += 2;
return 0;
}
int mul4(void)
{
x *= 4;
return 0;
}
int neg(void)
{
x = -x;
return 0;
}
void dummy(int a, int b, int c)
{
}
int main()
{
dummy(add2(), mul4(), neg());
printf("%d\n", x);
}
Unspecified behavior isn't exactly wonderful, but it's better than
undefined behavior.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-05-07 16:38 +0200 |
| Subject | Re: Optimization techniques and undefined behavior |
| Message-ID | <19-05-053@comp.compilers> |
| In reply to | #2246 |
On 02/05/2019 19:18, Kaz Kylheku wrote:
> On 2019-04-28, David Brown <david.brown@hesbynett.no> wrote:
>> On 26/04/2019 04:26, Kaz Kylheku wrote:
>>> On 2019-04-25, David Brown <david.brown@hesbynett.no> wrote:
>>>> It knows that "x * 2 / 2" is "x". It knows that "x + 1 > x" is true.
>>>
>>> Also, we could have it so that multiplication wraps, and yet in the same
>>> breath allow algebraic reductions like this anyway.
>>>
>>> Basically it can be so that, if overflow takes place in the abstract
>>> semantics of "x * 2 / 2", the result can be either the truncated
>>> version, or just x, if the algebraic reduction took place.
>>>
>>
>> I am afraid I don't understand you here. Are you saying that you could
>> define the language's arithmetic so that, given "x * 2 / 2", the
>> compiler could return /either/ "x" or the result you would get from
>> wrapped overflow calculations? You are defining two possible "correct"
>> answers?
>
> I'm fairly comfortable with this, because it maps to the familiar ISO C
> concept of "unspecified behavior".
OK. I can appreciate that, and would consider "signed integer overflow
has unspecified behaviour" as a reasonable choice.
>
> For instance, this program can produce one of the results -12, -6, -2
> or 4, based on which of the six permutations over the order in which the
> three functions are called.
>
> #include <stdio.h>
>
> int x = 1;
>
> int add2(void)
> {
> x += 2;
> return 0;
> }
>
> int mul4(void)
> {
> x *= 4;
> return 0;
> }
>
> int neg(void)
> {
> x = -x;
> return 0;
> }
>
> void dummy(int a, int b, int c)
> {
> }
>
> int main()
> {
> dummy(add2(), mul4(), neg());
> printf("%d\n", x);
> }
>
> Unspecified behavior isn't exactly wonderful, but it's better than
> undefined behavior.
>
It /can/ be better, but it is not always better.
People often misunderstand what unspecified behaviour means. For
example, it is possible for different runs of your program here to
produce different results - unspecified results don't need to be
consistent on different runs.
But if you write:
int main() {
dummy(add2(), mul4(), neg());
if (x == 4) printf("X is 4\n");
if (x != 4) printf("X is not 4\n");
}
then for any run of the program, one of the two statements must be
printed. If "dummy" had undefined behaviour, /neither/ of them would
have to be printed. So undefined behaviour can give more optimisation
opportunities (not that they are helpful in this case).
And with dummy() giving unspecified behaviour, the compiler will accept
the code without complaint - otherwise you'd get endless realms of false
positive warnings. But if dummy() had undefined behaviour, a compiler
can warn you of your bug.
Still, I agree that unspecified values could sometimes be a nice
alternative.
[toc] | [prev] | [standalone]
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
Back to top | Article view | comp.compilers
csiph-web