--- Day changed Thu Jun 21 2018
07:01 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has quit [Ping timeout: 260 seconds]     
07:12 -!- roconnor [~roconnor@host-45-58-224-191.dyn.295.ca] has joined #secp256k1     
08:15 < roconnor> https://github.com/bitcoin-core/secp256k1/blob/0b7024185045a49a1a6a4c5615bf31c94f63d9c4/src/field_10x26_impl.h#L734-L748
08:16 < roconnor> should the temporary variables t3 through t7 be removed since they are only ever reassigned to r[3] ... r[7] ?
08:29 < roconnor> oh, or is some sort of aliasing allowed in the parameters?
08:56 < sipa> i don't understand
08:57 < roconnor> I see now that the temporary variables t3 thorugh t7 are need in case that r aliases with a or b.
08:58 < roconnor> That said, I'm not so familiar with the `restrict` keyword, so it sounds like `b` is not allowed to alias with `r` (or `a`) even though the code would work if it did alias.
08:59 < roconnor> Perhaps this helps the optimizer in some way at the risk of making the API dangerous.
09:02 < sipa> i don't understand what you mean by "removing the temporary variables"
09:02 < sipa> oh, you mean immediately assigning to r[i] rather than to temporaries?
09:04 < sipa> i believe that code was written before adding the restrict keyword
09:04 < roconnor> Well `a` is not restricted.
09:04 < roconnor> so the temporary variables are probably still needed.
09:05 < roconnor> But I don't really understand the use of the `restrict` keyword.
09:07 < sipa> it means that the compiler can issue an assignmemt to the memory pointed to by a or r, and not need to re-read a value it read from b
09:08 < roconnor> The code as it exists never reads from b after writing to r, I beleive.
09:09 < roconnor> (at least prior to any fancy rearranging the compiler might do)
09:10 < sipa> right, i guess it means the compiler is free to rearrange things in a way that these assignments may go earlier
09:10 < roconnor> but not rearrange it with respect to a.
09:10 < sipa> correct
09:10 < sipa> we could try if there's a performance difference between with restrict and without, and with temporaries and without
09:10 < roconnor> The thing is `a` is usually access at the same time as `b` because they are always accessed when computing a convolution.
09:11 < sipa> that restrict keyword may also have been added on all field mul implementations, because there was maybe one that could make use of it
09:11 < roconnor> I mean it's upto you.  Are you pink searing never to alias `b` with `a` or `r` everywhere?
09:11 < sipa> the compiler will check that
09:12 < sipa> (reasonably, it doesn't guarantee it)
09:16 < sipa> with the restrict keyword there, it is UB to call the function in a way where b aliases r or a
09:17 < sipa> the only caller of mul_inner is field_mul, a bit lower in the file, and it has a runtime check (in test mode) that r != b
09:17 < sipa> no test for a = b, though
09:21 < gmaxwell> Careful with benchmarking to determine the utility of restrict as its highly compiler specific.
09:21 < gmaxwell> Historically GCC didn't make great use of it though it has been improving.
09:22 < gmaxwell> TI's compiler lives and dies based on it. IIRC intel's compiler makes a lot more use of it.
09:22 < gmaxwell> I've generally been hesitant to push it because until very recently GCC wouldn't issue a warning even if you made detectable misuse of it.
10:45 < roconnor> Thanks to both of you.  I still find it a bit weird, but I think I understand the semantics.
10:46 < roconnor> Also I find #define VERIFY_BITS(x, n) do { } while(0) to be really funny.
10:47 < sipa> you know why that is?
10:50 < roconnor> not really.  I'm looking at https://stackoverflow.com/questions/7978620/whats-a-portable-way-to-implement-no-op-statement-in-c
10:50 < roconnor> Seems ((void)0) might produce compiler warnings?
10:50 < roconnor> I'm forced to define a loop invarant at every one of the noop loops :joy:
11:01 < gmaxwell> Run preprocessing to strip them out?
11:02 < gmaxwell> I mean, if you're working on analysis of the code, you can instead analize an alternative ifdef where VERIFY_BITS() gets nulled out another way.
11:03 < gmaxwell> (or for VERIFY_BITS where it actually gets elevated to an assertion on the ranges that you prove holds)
11:10 < roconnor> well, it's nice to analyse the code that is actually run.  Anyhow, I sort of exaggerate.  I wrote a tactic to pass through these emtpy loops.
11:11 < roconnor> The loop invariant is exactly the conition at that point the code.
11:11 < roconnor> so it is easy to automatically provide the loop invariant from the context in which the do statement occurs.
11:17 < gmaxwell> and yes, MSVC warns on a number of things that outside of microsoft were accepted no-op norms. :(
11:44 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Remote host closed the connection]     
11:45 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #secp256k1     
11:57 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-ypgkzdfskfnwgarw] has joined #secp256k1     
12:15 -!- belcher [~belcher@unaffiliated/belcher] has joined #secp256k1     
12:33 -!- jtimon [~quassel@40.28.134.37.dynamic.jazztel.es] has joined #secp256k1     
13:52 < roconnor> sipa: should I add a VERIFY_CHECK(a != b); to secp256k1_fe_mul?
13:54 < roconnor> Though, *technically* we need to check that r and b don't intersect and a and b don't intersect.
13:54 < roconnor> I'm not sure how to legally do that though. :D
13:59 < andytoshi> i'd appreciate such a verify_check
14:00 < roconnor> The other thing to do is actually check if a = b and call into square in that case; however I expect we don't want to do that.
14:01 < andytoshi> nah, the programmer can just do that themselves
14:02 < sipa> roconnor: yes, please
14:02 < sipa> the code could be exhibiting UB if invoked with a ==b and undetected by the compiler
14:02 < sipa> (i just tried myself and all tests run fine with it)
14:02 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has joined #secp256k1     
14:05 -!- roconnor [~roconnor@host-45-58-224-191.dyn.295.ca] has quit [Ping timeout: 255 seconds]     
14:31 < gmaxwell> rconnor: if there is a restrict on them, GCC will just compile out that code and not even warn.
14:31 < gmaxwell> when restrict was first added in gcc _that_ was basically the only optimization I was able to get restrict to do. :P
14:31 < gmaxwell> Doesn't hurt to have them, but I expect it won't help much.
14:32 < gmaxwell> I recommend testing your test, and if it doesn't work, as I expect you note that its not expected to be reliable in a comment by the macro.
14:47 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-ypgkzdfskfnwgarw] has quit [Quit: Connection closed for inactivity]     
15:53 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 276 seconds]     
16:00 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-vxepeydrqewgohhs] has joined #secp256k1     
18:10 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-vxepeydrqewgohhs] has quit [Quit: Connection closed for inactivity]     
18:40 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-kacoxiiivikwfoot] has joined #secp256k1     
20:50 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-kacoxiiivikwfoot] has quit [Quit: Connection closed for inactivity]     
21:33 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Ping timeout: 250 seconds]     
21:38 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #secp256k1