LSUThorns/Vectors: Add kifneg function

Comments (9)

1. 

   Erik Schnetter reporter

   • changed title to LSUThorns/Vectors: Add kifneg function
   • changed status to open
   • removed comment

   • 2011-11-26T10:34:28+00:00
2. 

   Frank Löffler

   • removed comment

   This patch changes the definition of k8ifpos in file vectors-8-SSE2.h:240. Is this intended? Otherwise the patch looks ok (without testing it).

   • 2012-01-27T09:26:13+00:00
3. 

   Barry Wardell

   • removed comment

   How about adding your suggested ifmsb and implementing ifpos and ifneg in terms of that?

   • 2012-01-27T09:32:59+00:00
4. 

   Erik Schnetter reporter

   • removed comment

   ifmsb is implemented (just called ifneg), ifpos is implemented in terms of ifneg.

   Also, the definition of k8ipos is not changed -- the routine body has been changed, and the routine name has been changed from ifpos to ifneg, so the net change is neutral.

   • 2012-01-27T09:42:57+00:00
5. 

   Frank Löffler

   • removed comment

   If I look at line 240, that's inside a definition of k8ifpos, and that name is not changed. However, the entire block is inside an 'elif 0' - so it should not have an effect in the end. Doesn't this change the definition of k8ifpos inside that block? Could we remove that block at some point anyway, since it will never get executed?

   • 2012-01-27T09:56:44+00:00
6. 

   Barry Wardell

   • removed comment

   Replying to [comment:4 eschnett]:

   ifmsb is implemented (just called ifneg), ifpos is implemented in terms of ifneg.

   Yes, I saw that. My suggestion is to go ahead with renaming it to ifmsb and then add the trivial definition of ifneg = ifmsb. This would have the advantage that it would mean that only ifmsb would need to be implemented in each of the vectors-*.h files and ifpos/ifneg could be implemented just once in vectors.h

   Replying to [comment:5 knarf]:

   If I look at line 240, that's inside a definition of k8ifpos, and that name is not changed. However, the entire block is inside an 'elif 0' - so it should not have an effect in the end. Doesn't this change the definition of k8ifpos inside that block? Could we remove that block at some point anyway, since it will never get executed?

   That's how it looks to me too. Is there a reason to keep this if 0'd code around? If there is, then I think the unintentional change in the definition of k8ifpos should be corrected.

   • 2012-02-01T06:57:54+00:00
7. 

   Erik Schnetter reporter

   • removed comment

   Only implementing kifmsb, and defining kifpos and kifneg at a higher level, are a good idea.

   The #if 0 code is there because it is not always clear which code executes fastest. This also depends on the compiler. I'd like to keep this (slower, but still used-to-be-correct) variant around, augmented by a respective comment.

   • 2012-02-01T09:54:41+00:00
8. 

   Erik Schnetter reporter

   • changed status to resolved
   • removed comment

   Applied

   • 2012-02-04T18:21:15+00:00
9. 

   Roland Haas

   • edited description
   • changed status to closed

   • 2019-02-21T19:56:07+00:00
10. Log in to comment