Glad I could provide some value!

I appreciate the support Tiberius!

I was about to listen to that episode yesterday till they mentioned about Morgan's UKposts video. Now, back to the episode

link-time, to be precise

Thank you for the clarification.

I'm that guy :). Unfortunately, I haven't made any other talks on LLVM after this one. Thanks for the interest though!

@@MorganWilde you made a very good talk! I am a deep learning engineer and recently Swift got a good bit of attention as a potential deep learning language because of its LLVM compiler infrastructure. So I decided to learn more and this talk is a very good introduction. Thank you!

Everything start with llvm.org/

Yes, this is a valid mathematical optimization, regardless of the overflow consideration you mentioned.

@Sandeep it's also worth noting (specific to C/C++) that overflow behaviour is *undefined*, and compiler is free to do whatever it wants when you use undefined behaviour, including wiping your hard disk, or buying 42 box sets of the Fresh Prince of Bel Air using your credit card. Any code that relies on specific overflow behaviour is also undefined, according to the spec, and therefore its meaning does not need to be preserved. The result is that compilers can produce faster code, like in this example.

Luke Wren In case of signed integers, yes. With unsigned, overflow is not undefined behavior (also the reason why we should not used unsigned integers for loop increments and stuff)

That's true, you got me :)

Not a constant because the value of it can be assigned one it assigned cant be changed

@@3bdoelnaggar The value of constants is also assigned once inside the code :)

@@Sina-xw4xp inside code is constant inside runtime is immutable

@@3bdoelnaggar hmm. that depends on the language i guess. some languages allocate the constant value on runtime some don't. in case of rust it is as you said

Thanks for the comment!

IIRC it doesn't stand for anything, it's just the name