Re: not-a-number's

[Andreas Schwab]

Mischa Baars  writes:

> Furthermore, since 'fxam' will return a 'non-comparable' during the first
> compare, I suppose the function should then enter the first 'else' and
> return a '4'.

Non-comparable means that NaN != NaN is always true.

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: not-a-number's

[Mischa Baars]

On 01/16/2013 09:14 AM, Andreas Schwab wrote:

Mischa Baars  writes:


Furthermore, since 'fxam' will return a 'non-comparable' during the first
compare, I suppose the function should then enter the first 'else' and
return a '4'.

Non-comparable means that NaN != NaN is always true.

Andreas.


Sorry, let me correct, first I mean 'ftst' instead of 'fxam'.

This is the output of 'ftst' is according to the manual:

  [C3 C2 C1 C0] := [1 1 x 1] when not-comparable (this is where the 
not-a-numbers go)

  [C3 C2 C1 C0] := [0 0 x 0] when st(0) > 0
  [C3 C2 C1 C0] := [0 0 x 1] when st(0) < 0
  [C3 C2 C1 C0] := [1 0 x 0] when st(0) = 0

This means that the first 'if' statement should have been terminated 
when one or both of the arguments is a QNaN, entering the 'else' would 
be in error.
Also the second 'if' statement shouldn't be evaluated. This should also 
be true when the first 'if' is not enclosed by any 'isnan()'.


Furthermore, the manual states that any operation on a QNaN should 
return a QNaN.


Correct?

Re: not-a-number's

[Mischa Baars]

On 01/16/2013 08:57 AM, Eric Botcazou wrote:

Well, I have an Intel manual here that states that any operation on a
QNaN should return a QNaN, which means that also the compare should
return a QNaN when one or both of the arguments is a QNaN.

No, that isn't how comparisons work.  The correct result is 2 according to the
comparison rules of IEEE-754.  I'd suggest reading page 8 of "Lecture Notes on
the Status of IEEE 754" by Kahan:
   http://www.cs.berkeley.edu/~wkahan/ieee754status/IEEE754.PDF

Well, this is just a document of another teacher, this is not the Intel 
manual. Please read the other mail for me with the output of the 'ftst' 
instruction.

Re: not-a-number's

[Andreas Schwab]

Mischa Baars  writes:

> This means that the first 'if' statement should have been terminated when

There is no such thing as a "terminated statement".  The first condition
evaluates to true.

> Furthermore, the manual states that any operation on a QNaN should return
> a QNaN.

That is only true for arithmethic operations.  A comparison always
evaluates to true or false.

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: not-a-number's

[Jonathan Wakely]

On 16 January 2013 08:59, Mischa Baars wrote:
> On 01/16/2013 08:57 AM, Eric Botcazou wrote:
>>>
>>> Well, I have an Intel manual here that states that any operation on a
>>> QNaN should return a QNaN, which means that also the compare should
>>> return a QNaN when one or both of the arguments is a QNaN.
>>
>> No, that isn't how comparisons work.  The correct result is 2 according to
>> the
>> comparison rules of IEEE-754.  I'd suggest reading page 8 of "Lecture
>> Notes on
>> the Status of IEEE 754" by Kahan:
>>http://www.cs.berkeley.edu/~wkahan/ieee754status/IEEE754.PDF
>>
> Well, this is just a document of another teacher, this is not the Intel
> manual. Please read the other mail for me with the output of the 'ftst'
> instruction.

Do you know who Kahan is?

Re: not-a-number's

[Mischa Baars]

On 01/16/2013 10:06 AM, Andreas Schwab wrote:

Mischa Baars  writes:


This means that the first 'if' statement should have been terminated when

There is no such thing as a "terminated statement".  The first condition
evaluates to true.
Whatever you want, although personally I think it is very unlikely that 
'2' is the correct value to return :)





Furthermore, the manual states that any operation on a QNaN should return
a QNaN.

That is only true for arithmethic operations.  A comparison always
evaluates to true or false.

Andreas.

Identical basic blocks live long in RTL flow.

[Bin.Cheng]

Hi,
For below simple function from newlib:

static int
is_option (char *argv_element, int only)
{
  return ((argv_element == 0)
  || (argv_element[0] == '-') || (only && argv_element[0] == '+'));
}

The expanded rtl is like:

9: NOTE_INSN_BASIC_BLOCK 2
2: r113:SI=r0:SI
3: r114:SI=r1:SI
4: NOTE_INSN_FUNCTION_BEG
   11: pc={(r113:SI==0)?L39:pc}
  REG_BR_PROB 0x3f6
   12: NOTE_INSN_BASIC_BLOCK 3
   13: r111:SI=zero_extend([r113:SI])
   14: pc={(r111:SI==0x2d)?L43:pc}
  REG_BR_PROB 0x7c7
   15: NOTE_INSN_BASIC_BLOCK 4
   16: pc={(r114:SI!=0)?L20:pc}
  REG_BR_PROB 0x1388
   22: L22:
   17: NOTE_INSN_BASIC_BLOCK 5
6: r110:SI=0
   20: L20:
   21: NOTE_INSN_BASIC_BLOCK 6
   23: pc={(r111:SI!=0x2b)?L22:pc}
  REG_BR_PROB 0x1f49
   35: NOTE_INSN_BASIC_BLOCK 7
8: r110:SI=0x1
   39: L39:
   38: NOTE_INSN_BASIC_BLOCK 8
7: r110:SI=0x1
   43: L43:
   42: NOTE_INSN_BASIC_BLOCK 9
5: r110:SI=0x1
   24: L24:
   25: NOTE_INSN_BASIC_BLOCK 10
   26: r112:SI=r110:SI
   30: r0:SI=r112:SI
   33: use r0:SI

Basic blocks 8/9/10 are identical and live until pass jump2, which is
after register allocation.
I think these duplicated BBs do not contain additional information and
should be better to be removed ASAP, because they might interfere with
other passes like ifcvt.

So should this issue be handled like in jump pass?

Thanks in advance.
BTW, The compilation command line is:
arm-none-eabi-gcc -mthumb -mcpu=cortex-m0 -Os ...
--
Best Regards.

Re: not-a-number's

[Andrew Haley]

On 01/16/2013 09:27 AM, Mischa Baars wrote:
> On 01/16/2013 10:06 AM, Andreas Schwab wrote:
>> Mischa Baars  writes:
>>
>>> This means that the first 'if' statement should have been terminated when
>> There is no such thing as a "terminated statement".  The first condition
>> evaluates to true.
> Whatever you want, although personally I think it is very unlikely that 
> '2' is the correct value to return :)

Let's go through this line by line.  If there's anything you disagree
with, speak up.  But if you disagree that GCC has implemented C
correctly according to the standard, you must quote the relevant
sections of the document and explain your belief, not in terms of what
you think it should do, but in terms of what the standard actually
says.

Comparisons with NaN don't terminate a statement, and they don't
return a NaN.  They return a boolean.

Here's what Standard C, F.8.3 Relational operators, says:

 x != x → false The statement x != x is true if x is a NaN.

 x == x → true  The statement x == x is false if x is a NaN.

So:

{
double r = -NAN;

//  if (!isnan(y) && !isnan(x))
//  {
double a = absd(x);
double b = absd(y);

if (b != a)

If one of a or b is a NaN,  the comparison is unordered, so we take this branch.

{
if (b < a)

If one of a or b is a NaN, the comparison is unordered, so it returns
false.  We'll take the else branch.

{
if (b != 0) // octant 1, 4, 5 and 8 
(open set)
{
r = 0;
}
else// x-axis
{
r = 1;
}
}
else
{
if (a != 0) // octant 2, 3, 6 and 7 
(open set)

If a is a NaN, the comparison is unordered, so != returns true.  So we
take this branch and return 2.

{
r = 2;  // not-a-number's ???
}
else// y-axis
{
r = 3;
}
}
}
else// between axes
{
r = 4;
}
//  }

Andrew.

Re: not-a-number's

[Mischa Baars]

On 01/16/2013 12:07 PM, Andrew Haley wrote:

On 01/16/2013 09:27 AM, Mischa Baars wrote:

On 01/16/2013 10:06 AM, Andreas Schwab wrote:

Mischa Baars  writes:


This means that the first 'if' statement should have been terminated when

There is no such thing as a "terminated statement".  The first condition
evaluates to true.

Whatever you want, although personally I think it is very unlikely that
'2' is the correct value to return :)

Let's go through this line by line.  If there's anything you disagree
with, speak up.  But if you disagree that GCC has implemented C
correctly according to the standard, you must quote the relevant
sections of the document and explain your belief, not in terms of what
you think it should do, but in terms of what the standard actually
says.

Comparisons with NaN don't terminate a statement, and they don't
return a NaN.  They return a boolean.

They shouldn't return anything, the comparison should be terminated.


Here's what Standard C, F.8.3 Relational operators, says:

  x != x → falseThe statement x != x is true if x is a NaN.

  x == x → true  The statement x == x is false if x is a NaN.

So:

{
 double r = -NAN;

This should be the value returned.


//  if (!isnan(y) && !isnan(x))
//  {
 double a = absd(x);
 double b = absd(y);

 if (b != a)
Right here evaluation should be terminated, when one or both of the 
arguments are NaN. The statement becomes invalid.


If one of a or b is a NaN,  the comparison is unordered, so we take this branch.

 {
 if (b < a)

If one of a or b is a NaN, the comparison is unordered, so it returns
false.  We'll take the else branch.

 {
 if (b != 0) // octant 1, 4, 5 and 
8 (open set)
 {
 r = 0;
 }
 else// x-axis
 {
 r = 1;
 }
 }
 else
 {
 if (a != 0) // octant 2, 3, 6 and 
7 (open set)

If a is a NaN, the comparison is unordered, so != returns true.  So we
take this branch and return 2.

 {
 r = 2;  // not-a-number's ???
 }
 else// y-axis
 {
 r = 3;
 }
 }
 }
 else// between axes
 {
 r = 4;
 }
//  }

Andrew.

Re: not-a-number's

[Mischa Baars]

On 01/16/2013 12:07 PM, Andrew Haley wrote:

On 01/16/2013 09:27 AM, Mischa Baars wrote:

On 01/16/2013 10:06 AM, Andreas Schwab wrote:

Mischa Baars  writes:


This means that the first 'if' statement should have been terminated when

There is no such thing as a "terminated statement".  The first condition
evaluates to true.

Whatever you want, although personally I think it is very unlikely that
'2' is the correct value to return :)

Let's go through this line by line.  If there's anything you disagree
with, speak up.  But if you disagree that GCC has implemented C
correctly according to the standard, you must quote the relevant
sections of the document and explain your belief, not in terms of what
you think it should do, but in terms of what the standard actually
says.

Comparisons with NaN don't terminate a statement, and they don't
return a NaN.  They return a boolean.

Here's what Standard C, F.8.3 Relational operators, says:

  x != x → falseThe statement x != x is true if x is a NaN.

  x == x → true  The statement x == x is false if x is a NaN.
And indeed apparently the answer then is '2'. However, I don't think 
this is correct. If that means that there is an error in the C 
specification, then there probably is an error in the specification.


So:

{
 double r = -NAN;

//  if (!isnan(y) && !isnan(x))
//  {
 double a = absd(x);
 double b = absd(y);

 if (b != a)

If one of a or b is a NaN,  the comparison is unordered, so we take this branch.

 {
 if (b < a)

If one of a or b is a NaN, the comparison is unordered, so it returns
false.  We'll take the else branch.

 {
 if (b != 0) // octant 1, 4, 5 and 
8 (open set)
 {
 r = 0;
 }
 else// x-axis
 {
 r = 1;
 }
 }
 else
 {
 if (a != 0) // octant 2, 3, 6 and 
7 (open set)

If a is a NaN, the comparison is unordered, so != returns true.  So we
take this branch and return 2.

 {
 r = 2;  // not-a-number's ???
 }
 else// y-axis
 {
 r = 3;
 }
 }
 }
 else// between axes
 {
 r = 4;
 }
//  }

Andrew.

Re: not-a-number's

[Robert Dewar]

On 1/16/2013 6:54 AM, Mischa Baars wrote:
]

And indeed apparently the answer then is '2'. However, I don't think
this is correct. If that means that there is an error in the C
specification, then there probably is an error in the specification.


The C specification seems perfectly reasonable to me (in fact it is
rather familiar that x != x is a standard test for something being
a NaN. The fact that you for unclear reasons don't like the C spec
does not mean it is wrong!

Re: not-a-number's

[Mischa Baars]

On 01/16/2013 01:04 PM, Robert Dewar wrote:

On 1/16/2013 6:54 AM, Mischa Baars wrote:
]

And indeed apparently the answer then is '2'. However, I don't think
this is correct. If that means that there is an error in the C
specification, then there probably is an error in the specification.


The C specification seems perfectly reasonable to me (in fact it is
rather familiar that x != x is a standard test for something being
a NaN. The fact that you for unclear reasons don't like the C spec
does not mean it is wrong!

And as I have said before: if you are satisfied with the answer '2', 
then so be it and you keep the compiler the way it is, personally I'm am 
not able to accept changes to the sources anyway. I don't think it is 
the right answer though.


Mischa.

Re: not-a-number's

[Robert Dewar]

On 1/16/2013 7:10 AM, Mischa Baars wrote:


And as I have said before: if you are satisfied with the answer '2',
then so be it and you keep the compiler the way it is, personally I'm am
not able to accept changes to the sources anyway. I don't think it is
the right answer though.


The fact that you don't think that gcc shoudl follow the C standard
is hardly convincing unless it is backed up by convincing technical
argument. I see nothing surprising about the 2 here, indeed any other
answer *would* be surprising. I still don't understand the basis for
your non-stnadard views.


Mischa.

Re: not-a-number's

[Mischa Baars]

On 01/16/2013 01:28 PM, Robert Dewar wrote:

On 1/16/2013 7:10 AM, Mischa Baars wrote:


And as I have said before: if you are satisfied with the answer '2',
then so be it and you keep the compiler the way it is, personally I'm am
not able to accept changes to the sources anyway. I don't think it is
the right answer though.


The fact that you don't think that gcc shoudl follow the C standard
is hardly convincing unless it is backed up by convincing technical
argument. I see nothing surprising about the 2 here, indeed any other
answer *would* be surprising. I still don't understand the basis for
your non-stnadard views.


Mischa.





Let me explain again for you. Every 'if' statement in C is translated 
into a 'fucom' or similar instruction, which sets a number of conditions 
flags in the co-processor. Some instructions need you to load these into 
the eflags register manually, others don't.


Now, as soon as the 'fucom' or similar instruction encounters a 
'signalling not-a-number' or 'quiet not-a-number' as one or both of it's 
arguments, the condition code is set to 'not comparable'. This has 
nothing to do with the C specification, but purely with the Intel/AMD 
hardware.


If you ask me, it would be counter-intuitive to change the value of the 
condition code to some other value and call that the new standard. 
Instead it would seem logical to use the 'not comparable' and terminate 
the 'if' statement.


Does that make sense to you?

In our example, a 'not-a-number' would be returned to the main program, 
without the need for an extra 'isnan()'.


Mischa.

Re: not-a-number's

[Andrew Haley]

On 01/16/2013 11:54 AM, Mischa Baars wrote:
>> Here's what Standard C, F.8.3 Relational operators, says:
>> >
>> >   x != x → false   The statement x != x is true if x is a NaN.
>> >
>> >   x == x → true  The statement x == x is false if x is a NaN.
>
> And indeed apparently the answer then is '2'. However, I don't think 
> this is correct. If that means that there is an error in the C 
> specification, then there probably is an error in the specification.

Right.  So we are agreed that GCC does what the specification of
the C programming language says it must do.  Any argument that you
have must, therefore, be with the technical committee of ISO C, not
with us.

Andrew.

Re: not-a-number's

[Richard Biener]

On Wed, Jan 16, 2013 at 1:52 PM, Mischa Baars  wrote:
> On 01/16/2013 01:28 PM, Robert Dewar wrote:
>>
>> On 1/16/2013 7:10 AM, Mischa Baars wrote:
>>
>>> And as I have said before: if you are satisfied with the answer '2',
>>> then so be it and you keep the compiler the way it is, personally I'm am
>>> not able to accept changes to the sources anyway. I don't think it is
>>> the right answer though.
>>
>>
>> The fact that you don't think that gcc shoudl follow the C standard
>> is hardly convincing unless it is backed up by convincing technical
>> argument. I see nothing surprising about the 2 here, indeed any other
>> answer *would* be surprising. I still don't understand the basis for
>> your non-stnadard views.
>>>
>>>
>>> Mischa.
>>>
>>
>
> Let me explain again for you. Every 'if' statement in C is translated into a
> 'fucom' or similar instruction, which sets a number of conditions flags in
> the co-processor. Some instructions need you to load these into the eflags
> register manually, others don't.
>
> Now, as soon as the 'fucom' or similar instruction encounters a 'signalling
> not-a-number' or 'quiet not-a-number' as one or both of it's arguments, the
> condition code is set to 'not comparable'. This has nothing to do with the C
> specification, but purely with the Intel/AMD hardware.
>
> If you ask me, it would be counter-intuitive to change the value of the
> condition code to some other value and call that the new standard. Instead
> it would seem logical to use the 'not comparable' and terminate the 'if'
> statement.
>
> Does that make sense to you?
>
> In our example, a 'not-a-number' would be returned to the main program,
> without the need for an extra 'isnan()'.

You can enable FP exceptions via fpsetexceptflag and friends (it's disabled
in the FPU by default) and if you then make sure to compile with
-fsignalling-nans (that's not the default) you will get the desired behavior
(program termination via an exception).

Richard.

> Mischa.

Re: not-a-number's

[Tim Prince]

On 1/16/2013 5:00 AM, Andrew Haley wrote:

On 01/16/2013 11:54 AM, Mischa Baars wrote:

Here's what Standard C, F.8.3 Relational operators, says:

   x != x → false   The statement x != x is true if x is a NaN.

   x == x → true  The statement x == x is false if x is a NaN.

And indeed apparently the answer then is '2'. However, I don't think
this is correct. If that means that there is an error in the C
specification, then there probably is an error in the specification.

Right.  So we are agreed that GCC does what the specification of
the C programming language says it must do.  Any argument that you
have must, therefore, be with the technical committee of ISO C, not
with us.

Andrew.

There exist compilers which have options to ignore the possibility of 
NaN and replace x == x  by 1 and x != x by 0 at compile time. gcc is 
undoubtedly correct in not making such replacements as a default in 
violation of C specification.


--
Tim Prince

Re: not-a-number's

[Andreas Schwab]

Richard Biener  writes:

> You can enable FP exceptions via fpsetexceptflag and friends (it's disabled
> in the FPU by default) and if you then make sure to compile with
> -fsignalling-nans (that's not the default) you will get the desired behavior
> (program termination via an exception).

That will only work with SNaN, and only for input operands, since the
FPU will never generate SNaN on its own.

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: not-a-number's

[Vincent Lefevre]

On 2013-01-16 12:47:46 +0100, Mischa Baars wrote:
> On 01/16/2013 12:07 PM, Andrew Haley wrote:
> >Comparisons with NaN don't terminate a statement, and they don't
> >return a NaN.  They return a boolean.
> They shouldn't return anything, the comparison should be terminated.

This depends on the comparison and the context. You have quiet and
signaling comparisons. != and == are quiet comparisons: they never
generate an exception on quiet NaN operands. <, <=, >=, > are
signaling comparisons: they generate an exception on quiet NaN
operands; but the comparison will be interrupted only if you trap
the invalid operation exception.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: not-a-number's

[Ian Lance Taylor]

On Wed, Jan 16, 2013 at 4:52 AM, Mischa Baars  wrote:
>
> Let me explain again for you. Every 'if' statement in C is translated into a
> 'fucom' or similar instruction, which sets a number of conditions flags in
> the co-processor. Some instructions need you to load these into the eflags
> register manually, others don't.
>
> Now, as soon as the 'fucom' or similar instruction encounters a 'signalling
> not-a-number' or 'quiet not-a-number' as one or both of it's arguments, the
> condition code is set to 'not comparable'. This has nothing to do with the C
> specification, but purely with the Intel/AMD hardware.
>
> If you ask me, it would be counter-intuitive to change the value of the
> condition code to some other value and call that the new standard. Instead
> it would seem logical to use the 'not comparable' and terminate the 'if'
> statement.

You appear to be confusing the details of processor implementation
with the C language.  The C language is defined by a language
standard, not by processor implementations.  The language standard
defines how NaN values should behave on systems that use them.

If you want a C program to act in some other way, you need to describe
that change in terms of the C language, not in terms of a processor
implementation.  For example, you could say "if any function does a
comparison of floating point values, and one of the floating point
values is a NaN, then the function should return immediately.  The
return value should be "  You are going to have to finish that
sentence, because I have no idea what you intend.

Ian

Re: not-a-number's

[Vincent Lefevre]

On 2013-01-16 14:53:42 +0100, Richard Biener wrote:
> You can enable FP exceptions via fpsetexceptflag and friends (it's
> disabled in the FPU by default) and if you then make sure to compile
> with -fsignalling-nans (that's not the default) you will get the
> desired behavior (program termination via an exception).

By "enable FP exceptions", I think you mean set a trap for these
exceptions (documents often mix "exception" and "trap"). But there
doesn't seem to be standard support for traps in C. The Glibc
provides feenableexcept, fedisableexcept and fegetexcept functions
for that.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Identical basic blocks live long in RTL flow.

[Jeff Law]

On 01/16/2013 02:28 AM, Bin.Cheng wrote:

Hi,
For below simple function from newlib:

static int
is_option (char *argv_element, int only)
{
   return ((argv_element == 0)
   || (argv_element[0] == '-') || (only && argv_element[0] == '+'));
}

The expanded rtl is like:

 9: NOTE_INSN_BASIC_BLOCK 2
 2: r113:SI=r0:SI
 3: r114:SI=r1:SI
 4: NOTE_INSN_FUNCTION_BEG
11: pc={(r113:SI==0)?L39:pc}
   REG_BR_PROB 0x3f6
12: NOTE_INSN_BASIC_BLOCK 3
13: r111:SI=zero_extend([r113:SI])
14: pc={(r111:SI==0x2d)?L43:pc}
   REG_BR_PROB 0x7c7
15: NOTE_INSN_BASIC_BLOCK 4
16: pc={(r114:SI!=0)?L20:pc}
   REG_BR_PROB 0x1388
22: L22:
17: NOTE_INSN_BASIC_BLOCK 5
 6: r110:SI=0
20: L20:
21: NOTE_INSN_BASIC_BLOCK 6
23: pc={(r111:SI!=0x2b)?L22:pc}
   REG_BR_PROB 0x1f49
35: NOTE_INSN_BASIC_BLOCK 7
 8: r110:SI=0x1
39: L39:
38: NOTE_INSN_BASIC_BLOCK 8
 7: r110:SI=0x1
43: L43:
42: NOTE_INSN_BASIC_BLOCK 9
 5: r110:SI=0x1
24: L24:
25: NOTE_INSN_BASIC_BLOCK 10
26: r112:SI=r110:SI
30: r0:SI=r112:SI
33: use r0:SI

Basic blocks 8/9/10 are identical and live until pass jump2, which is
after register allocation.
I think these duplicated BBs do not contain additional information and
should be better to be removed ASAP, because they might interfere with
other passes like ifcvt.

So should this issue be handled like in jump pass?

In this case, I'd expect DCE to optimize away the redundant assignments.



jeff

Re: Identical basic blocks live long in RTL flow.

[Jan Hubicka]

> >
> >Basic blocks 8/9/10 are identical and live until pass jump2, which is
> >after register allocation.
> >I think these duplicated BBs do not contain additional information and
> >should be better to be removed ASAP, because they might interfere with
> >other passes like ifcvt.
> >
> >So should this issue be handled like in jump pass?
> In this case, I'd expect DCE to optimize away the redundant assignments.

Yeah, we also used to be able to optimize these out in crossjumping before
regalloc but with SSA we now produce different pseudos in different copies so I
think it was path by Steven that disabled crossjumping proir jump2 (both passes
also ought to be renamed)

Honza
> 
> 
> 
> jeff

Re: not-a-number's

[David Paterson]

> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf
> Of Mischa Baars
> Sent: 16 January 2013 12:53
> To: Robert Dewar; gcc@gcc.gnu.org
> Subject: Re: not-a-number's
>
> On 01/16/2013 01:28 PM, Robert Dewar wrote:
> > On 1/16/2013 7:10 AM, Mischa Baars wrote:
> >
> >> And as I have said before: if you are satisfied with the answer
> >> '2', then so be it and you keep the compiler the way it is,
> >> personally I'm am not able to accept changes to the sources anyway.
> >> I don't think it is the right answer though.
> >
> > The fact that you don't think that gcc shoudl follow the C standard
> > is hardly convincing unless it is backed up by convincing technical
> > argument. I see nothing surprising about the 2 here, indeed any
> > other answer *would* be surprising. I still don't understand the
> > basis for your non-stnadard views.
> >>
> >> Mischa.
> >>
> >
>
> Let me explain again for you. Every 'if' statement in C is translated into a 
> 'fucom'
> or similar instruction, which sets a number of conditions flags in the 
> co-processor.
> Some instructions need you to load these into the eflags register
> manually, others don't.
>
> Now, as soon as the 'fucom' or similar instruction encounters a
> 'signalling not-a- number' or 'quiet not-a-number' as one or both of
> it's arguments, the condition code is set to 'not comparable'. This
> has nothing to do with the C specification, but purely with the Intel/AMD 
> hardware.

Intel and AMD aren't the only manufacturers or developers of floating
point hardware.  Plus there are software implementations to consider
as well.

In order for different hardware and software implementations to work
correctly with each other, there have to be standards defining all
aspects of their operation.  The same applies to the C language (and
other languages!).

Without standards we'd have no way to ensure programs would run in the
same way on different hardware, or when using different compilers...

> If you ask me, it would be counter-intuitive to change the value of
> the condition code to some other value and call that the new standard.
> Instead it would seem logical to use the 'not comparable' and terminate the 
> 'if'
> statement.

What exactly do you mean by "terminate the if"??  Do you mean skip the
whole compound statement, including any "else" clause?

> Does that make sense to you?
>
> In our example, a 'not-a-number' would be returned to the main
> program, without the need for an extra 'isnan()'.

"...returned to the main program" doesn't make sense.  How is the
compiler going to figure out what to return and when?  What does it
return from a void, or int function?

I'm sorry you don't like the way it's implemented, but we have
standards for very good reasons, and  although this particular one may
seem a bit counter- intuitive, it's well known, and many programs rely
on it operating as it does.

But, if you want to change the standards, by all means try...

David P.

isl-0.10 and cloog-0.17.0 removed from ftp server

[Mike Stump]

Someone removed isl-0.10.tar.bz2 and cloog-0.17.0.tar.gz from 
ftp://gcc.gnu.org/pub/gcc/infrastructure.  I'd hoping this was in error and the 
files can be restored.  If there is some compelling reason, I am interested.

Re: isl-0.10 and cloog-0.17.0 removed from ftp server

[Richard Biener]

Mike Stump  wrote:

>Someone removed isl-0.10.tar.bz2 and cloog-0.17.0.tar.gz from
>ftp://gcc.gnu.org/pub/gcc/infrastructure.  I'd hoping this was in error
>and the files can be restored.  If there is some compelling reason, I
>am interested.

I removed them in favor of the now documented as recommended versions 0.18.0 
and 0.11.1. The old versions are not required or supported by any released gcc 
version.

Richard.

Caller save mode on MIPS

[Fu, Chao-Ying]

Hi All,

  From testing, I found out that the whole width of a MIPS 
integer/floating-point register
is saved and restored around a call.  This may hurt the performance.

Ex:
fu@debian6:/disk/fu/dev/test$ cat add2.c
void test2(float);

float test(float a, float b)
{
  test2(a*b);
  return a;
}

fu@debian6:/disk/fu/dev/test$ gcc -S -O2 add2.c -mips64r2 -mabi=n32

(# Or )

fu@debian6:/disk/fu/dev/test$ gcc -S -O2 add2.c -mips32r2 -mfp64

fu@debian6:/disk/fu/dev/test$ grep f0 add2.s
mov.s   $f0,$f12 <
sdc1$f0,24($sp) <
ldc1$f0,24($sp) <

The 64-bit $f0 is saved and restored via sdc1 and ldc1.  However, using lwc1 
and swc1 should be ok and faster.

  From http://gcc.gnu.org/ml/gcc-patches/2001-02/msg01480.html,
the patch defines HARD_REGNO_CALLER_SAVE_MODE to return proper mode for i386.
For MIPS, we may have:
Ex:
#define HARD_REGNO_CALLER_SAVE_MODE(REGNO, NREGS, MODE) \
   ((MODE) == VOIDmode ? choose_hard_reg_mode ((REGNO), (NREGS), false) \
   : (MODE))

  Any feedback about adding HARD_REGNO_CALLER_SAVE_MODE to MIPS?  Thanks!

Regards,
Chao-ying

missing optimization "a << (b & 63) to a << b"

[Wei Mi]

Hi,

For x86, shift insn will automatically mask the count to 5 bits in 32
bit mode and to 6 bits in 64 bit mode, so for the testcase below, the
buf_ << (-end & 63) could be optimized to buf_ << -end. But for trunk
compiler, some place in the testcase is not optimized.

typedef unsigned long long uint64;
typedef unsigned int uint32;

class Decoder {
 public:
 Decoder() : k_minus_1_(0), buf_(0), bits_left_(0) {}
 ~Decoder() {}

 uint32 ExtractBits(uint64 end, uint64 start);
 inline uint32 GetBits(int bits) {
   uint32 val = ExtractBits(bits, 0);
   buf_ >>= bits;
   bits_left_ -= bits;
   return val;
 }

 uint32 Get(uint32 bits);

 uint32 k_minus_1_;
 uint64 buf_;
 unsigned long bits_left_;
};

uint32 Decoder::ExtractBits(uint64 end, uint64 start) {
 return (buf_ << (-end & 63)) >> ((start - end) & 63);
}

uint32 Decoder::Get(uint32 bits) {
 bits += k_minus_1_;
 uint32 msbit = (bits > (k_minus_1_ + 1));
 return GetBits(bits - msbit) | (msbit << (bits - 1));
}

The assembly generated by "g++ -O2 -S 1.C"

.file   "1.c"
.text
.align 2
.p2align 4,,15
.globl  _ZN7Decoder11ExtractBitsEyy
.type   _ZN7Decoder11ExtractBitsEyy, @function
_ZN7Decoder11ExtractBitsEyy:
.LFB7:
.cfi_startproc
movq8(%rdi), %rax
movl%esi, %ecx
negl%ecx
salq%cl, %rax   ===> Here (-end & 63) is
optimized away.
movl%edx, %ecx
subl%esi, %ecx
shrq%cl, %rax
ret
.cfi_endproc
.LFE7:
.size   _ZN7Decoder11ExtractBitsEyy, .-_ZN7Decoder11ExtractBitsEyy
.align 2
.p2align 4,,15
.globl  _ZN7Decoder3GetEj
.type   _ZN7Decoder3GetEj, @function
_ZN7Decoder3GetEj:
.LFB8:
.cfi_startproc
movl(%rdi), %eax
movq8(%rdi), %r8
addl%eax, %esi
addl$1, %eax
movq%r8, %r10
cmpl%esi, %eax
movl%esi, %ecx
setb%al
movzbl  %al, %eax
subl%eax, %ecx
movl%ecx, %edx
shrq%cl, %r10
movslq  %ecx, %r9
negl%edx
movq%r10, 8(%rdi)
subq%r9, 16(%rdi)
andl$63, %edx   ==> Inst A:  the (-end & 63) is
not optimized away.
movq%r8, %rdi
movl%edx, %ecx
salq%cl, %rdi ==> Inst B: use the result of
(-end & 63) here
shrq%cl, %rdi ==> Inst C: use the result of
(-end & 63) here
leal-1(%rsi), %ecx
sall%cl, %eax
orl %edi, %eax
ret
.cfi_endproc
.LFE8:

In Decoder::Get(), (-end & 63) in Inst A is not optimized away because
the two (-end & 63) exprs are csed after ExtractBits() is inlined to
GetBits() then to Get(), then it is a single def feeding to multiple
down uses, which cannot be optimized by combine phase. This is an old
problem in combine. It is also the reason why (-end & 63) is optimized
away in _ZN7Decoder11ExtractBitsEyy.

To overcome the weakness of combine phase for this testcase, I am
wondering whether we can extend fwprop to solve the problem because
fwprop handle those "single def to multiple down uses" cases. Existing
fwprop is restrictive since it only tries to propagate when the src of
def insn is a reg, subreg or const, and it only tries to propagate
when simplification after propagate can collapse the expr to a const.
Can we extend it to try propagate more complex exprs from def to use
(here propagate the andl operation from Inst A to the shift operands
in Inst B and Inst C), and let try_fwprop_subst in fwprop.c to decide
whether to keep the change by comparing the costs?

Or better way to solve the problem? Appreciated a lot!

Thanks,
Wei.

Re: missing optimization "a << (b & 63) to a << b"

[Xinliang David Li]

[cc list trimmed]


On Wed, Jan 16, 2013 at 5:44 PM, Wei Mi  wrote:
> Hi,
>
> For x86, shift insn will automatically mask the count to 5 bits in 32
> bit mode and to 6 bits in 64 bit mode, so for the testcase below, the
> buf_ << (-end & 63) could be optimized to buf_ << -end. But for trunk
> compiler, some place in the testcase is not optimized.
>
> typedef unsigned long long uint64;
> typedef unsigned int uint32;
>
> class Decoder {
>  public:
>  Decoder() : k_minus_1_(0), buf_(0), bits_left_(0) {}
>  ~Decoder() {}
>
>  uint32 ExtractBits(uint64 end, uint64 start);
>  inline uint32 GetBits(int bits) {
>uint32 val = ExtractBits(bits, 0);
>buf_ >>= bits;
>bits_left_ -= bits;
>return val;
>  }
>
>  uint32 Get(uint32 bits);
>
>  uint32 k_minus_1_;
>  uint64 buf_;
>  unsigned long bits_left_;
> };
>
> uint32 Decoder::ExtractBits(uint64 end, uint64 start) {
>  return (buf_ << (-end & 63)) >> ((start - end) & 63);
> }
>
> uint32 Decoder::Get(uint32 bits) {
>  bits += k_minus_1_;
>  uint32 msbit = (bits > (k_minus_1_ + 1));
>  return GetBits(bits - msbit) | (msbit << (bits - 1));
> }
>
> The assembly generated by "g++ -O2 -S 1.C"
>
> .file   "1.c"
> .text
> .align 2
> .p2align 4,,15
> .globl  _ZN7Decoder11ExtractBitsEyy
> .type   _ZN7Decoder11ExtractBitsEyy, @function
> _ZN7Decoder11ExtractBitsEyy:
> .LFB7:
> .cfi_startproc
> movq8(%rdi), %rax
> movl%esi, %ecx
> negl%ecx
> salq%cl, %rax   ===> Here (-end & 63) is
> optimized away.
> movl%edx, %ecx
> subl%esi, %ecx
> shrq%cl, %rax
> ret
> .cfi_endproc
> .LFE7:
> .size   _ZN7Decoder11ExtractBitsEyy, .-_ZN7Decoder11ExtractBitsEyy
> .align 2
> .p2align 4,,15
> .globl  _ZN7Decoder3GetEj
> .type   _ZN7Decoder3GetEj, @function
> _ZN7Decoder3GetEj:
> .LFB8:
> .cfi_startproc
> movl(%rdi), %eax
> movq8(%rdi), %r8
> addl%eax, %esi
> addl$1, %eax
> movq%r8, %r10
> cmpl%esi, %eax
> movl%esi, %ecx
> setb%al
> movzbl  %al, %eax
> subl%eax, %ecx
> movl%ecx, %edx
> shrq%cl, %r10
> movslq  %ecx, %r9
> negl%edx
> movq%r10, 8(%rdi)
> subq%r9, 16(%rdi)
> andl$63, %edx   ==> Inst A:  the (-end & 63) is
> not optimized away.
> movq%r8, %rdi
> movl%edx, %ecx
> salq%cl, %rdi ==> Inst B: use the result of
> (-end & 63) here
> shrq%cl, %rdi ==> Inst C: use the result of
> (-end & 63) here
> leal-1(%rsi), %ecx
> sall%cl, %eax
> orl %edi, %eax
> ret
> .cfi_endproc
> .LFE8:
>
> In Decoder::Get(), (-end & 63) in Inst A is not optimized away because
> the two (-end & 63) exprs are csed after ExtractBits() is inlined to
> GetBits() then to Get(), then it is a single def feeding to multiple
> down uses, which cannot be optimized by combine phase. This is an old
> problem in combine. It is also the reason why (-end & 63) is optimized
> away in _ZN7Decoder11ExtractBitsEyy.
>
> To overcome the weakness of combine phase for this testcase, I am
> wondering whether we can extend fwprop to solve the problem because
> fwprop handle those "single def to multiple down uses" cases. Existing
> fwprop is restrictive since it only tries to propagate when the src of
> def insn is a reg, subreg or const, and it only tries to propagate
> when simplification after propagate can collapse the expr to a const.
> Can we extend it to try propagate more complex exprs from def to use
> (here propagate the andl operation from Inst A to the shift operands
> in Inst B and Inst C), and let try_fwprop_subst in fwprop.c to decide
> whether to keep the change by comparing the costs?
>
> Or better way to solve the problem? Appreciated a lot!
>
> Thanks,
> Wei.

Re: not-a-number's

[Mischa Baars]

On 01/16/2013 02:53 PM, Richard Biener wrote:

On Wed, Jan 16, 2013 at 1:52 PM, Mischa Baars  wrote:

On 01/16/2013 01:28 PM, Robert Dewar wrote:

On 1/16/2013 7:10 AM, Mischa Baars wrote:


And as I have said before: if you are satisfied with the answer '2',
then so be it and you keep the compiler the way it is, personally I'm am
not able to accept changes to the sources anyway. I don't think it is
the right answer though.


The fact that you don't think that gcc shoudl follow the C standard
is hardly convincing unless it is backed up by convincing technical
argument. I see nothing surprising about the 2 here, indeed any other
answer *would* be surprising. I still don't understand the basis for
your non-stnadard views.


Mischa.


Let me explain again for you. Every 'if' statement in C is translated into a
'fucom' or similar instruction, which sets a number of conditions flags in
the co-processor. Some instructions need you to load these into the eflags
register manually, others don't.

Now, as soon as the 'fucom' or similar instruction encounters a 'signalling
not-a-number' or 'quiet not-a-number' as one or both of it's arguments, the
condition code is set to 'not comparable'. This has nothing to do with the C
specification, but purely with the Intel/AMD hardware.

If you ask me, it would be counter-intuitive to change the value of the
condition code to some other value and call that the new standard. Instead
it would seem logical to use the 'not comparable' and terminate the 'if'
statement.

Does that make sense to you?

In our example, a 'not-a-number' would be returned to the main program,
without the need for an extra 'isnan()'.

You can enable FP exceptions via fpsetexceptflag and friends (it's disabled
in the FPU by default) and if you then make sure to compile with
-fsignalling-nans (that's not the default) you will get the desired behavior
(program termination via an exception).

Richard.


Yes, I understand that more or less the same can be done with signaling 
not-a-numbers. By unmasking the appropriate bits in the exception mask, 
indeed the 'invalid operation' exception would be triggered on the first 
'if' statement. Probably the whole program including the 'main()' loop 
is terminated that way, but I have never looked at the actual handler 
more close, so I can't with certainty.
Also this was not what I intended to do, I was trying to work with quiet 
not-a-numbers explicitly to avoid the 'invalid operation' exception to 
be triggered, so that my program can work it's way through the 
calculations without being terminated by the intervention of a signal 
handler. When any not-a-number shows up in results after execution, then 
you know something went wrong. When the program does what it is supposed 
to do, you could remove any remaining debug code, such as the boundary 
check in the trigonometric functions.


Mischa.

Re: not-a-number's

[Mischa Baars]

On 01/16/2013 07:23 PM, David Paterson wrote:

-Original Message-
From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf
Of Mischa Baars
Sent: 16 January 2013 12:53
To: Robert Dewar; gcc@gcc.gnu.org
Subject: Re: not-a-number's

On 01/16/2013 01:28 PM, Robert Dewar wrote:

On 1/16/2013 7:10 AM, Mischa Baars wrote:


And as I have said before: if you are satisfied with the answer
'2', then so be it and you keep the compiler the way it is,
personally I'm am not able to accept changes to the sources anyway.
I don't think it is the right answer though.

The fact that you don't think that gcc shoudl follow the C standard
is hardly convincing unless it is backed up by convincing technical
argument. I see nothing surprising about the 2 here, indeed any
other answer *would* be surprising. I still don't understand the
basis for your non-stnadard views.

Mischa.


Let me explain again for you. Every 'if' statement in C is translated into a 
'fucom'
or similar instruction, which sets a number of conditions flags in the 
co-processor.
Some instructions need you to load these into the eflags register
manually, others don't.

Now, as soon as the 'fucom' or similar instruction encounters a
'signalling not-a- number' or 'quiet not-a-number' as one or both of
it's arguments, the condition code is set to 'not comparable'. This
has nothing to do with the C specification, but purely with the Intel/AMD 
hardware.

Intel and AMD aren't the only manufacturers or developers of floating
point hardware.  Plus there are software implementations to consider
as well.

In order for different hardware and software implementations to work
correctly with each other, there have to be standards defining all
aspects of their operation.  The same applies to the C language (and
other languages!).

Without standards we'd have no way to ensure programs would run in the
same way on different hardware, or when using different compilers...


If you ask me, it would be counter-intuitive to change the value of
the condition code to some other value and call that the new standard.
Instead it would seem logical to use the 'not comparable' and terminate the 'if'
statement.

What exactly do you mean by "terminate the if"??  Do you mean skip the
whole compound statement, including any "else" clause?

Yes, exactly. Skip it, including the 'else'.



Does that make sense to you?

In our example, a 'not-a-number' would be returned to the main
program, without the need for an extra 'isnan()'.

"...returned to the main program" doesn't make sense.  How is the
compiler going to figure out what to return and when?  What does it
return from a void, or int function?
There is an 'r = -NAN' at the beginning which will then be the value 
returned.


I'm sorry you don't like the way it's implemented, but we have
standards for very good reasons, and  although this particular one may
seem a bit counter- intuitive, it's well known, and many programs rely
on it operating as it does.

But, if you want to change the standards, by all means try...

David P.