Permalink
Reply
On Monday, 9 January 2023 at 17:26:58 UTC, deadalnix wrote:
>On Sunday, 8 January 2023 at 03:11:15 UTC, Siarhei Siamashka wrote:
>What's the best way to get some inline LLVM IR optimizations for Int128 included in the next release of LDC? So that it works fast out of the box. The struct alignment is causing some troubles though.
I'm going to be the party pooper but this is completely and 100% useless work. It's not a dunk on you and your work, more on all the decision that preceeds it that lead to you even attempting to do this.
D has cent/ucent, and what's required is actually support that. At some point, someone decided nonono, what we need instead is a retarded library implementation that is obviously going to be terrible, and that will then lead people to be like, hey we can improve this with intrinsics, specific for each compiler and plateform, and now we have this thread, where well meaning people are putting in work to solve problem we shouldn't be having in the first place.
All modern backends understand the concept of an int128, so it's literally half an hour of work to support this in LDC/GDC. The fact Walter chose to have its own backend to maintain is all well and good, but it is not my problem as a user, nor it is the problem of most people here. Just forward cent/ucent to core.int128 in there and generate horrible codegen for all that matter if it cannot support int128.
And just in case you wonder who I am to assert this forcefully: I'm the guy who made it so that LLVM generate half decent codegen for int128 to begin with. I'm very familiar with the problem, in fact, as frightening as it may seems, I may even be one of the world finest expert on the matter (a very scary prospect indeed). Don't believe me? https://reviews.llvm.org/D29872
I vote for this. Consider also that integers in D have VRP and implicit conversions and so on so 128 bit types not having this is (although not the end of the world[1]) not good.
[1] I say this, because 128 bit ints are not used often in the grand scheme of things but when you do need them they are typically quite densely used in that code (e.g. crypto), which is why they aren't library types with magic intrinsic in other languages either.
