Casting function
Closed this issue · 9 comments
Let's implement one or more casting functions in standard.likely. As I see it, the casting scenarios are as follows:
- Casting to/from floating/integer representations.
- Casting to a different bitness.
- Both a & b.
Once this works, the basic math functions should make cast calls to ensure the input is floating point.
Sound good?
Sorry for the late response, I think this is a great idea I am looking to implement five functions: truncate, zero extend, sign extend, FPtoInt and InttoFP. One related question I have is the difference between the likely_hash h and the hash of Value* v in the matrix struct. Functions like setHash() change the hash of v but do not update h, and I believe the hash(v) and h should always correspond correct?
Yes, I believe they should correspond as well.
Sorry this is taking so long to complete but I'm worried a structural change to the code might be necessary to complete casting. The only thing left to do is to update the likely_hash within the MatrixStruct. This value however is const and cannot be changed when casting occurs. Perhaps you have already thought about this and have an easy solution (hopefully!)? If not I have given it some thought and propose removing the hash variable from the MatrixStruct entirely. Instead the already written accessor functions isFloating, isSigned etc. can be used and the saved hash and value are guaranteed to correspond. I think all that would need to be written is an accessor function to retrieve the hash value and convert it to a likely_hash so that it is still accessible. This method could have serious consequences that I have not foreseen but would solve the const issue I believe. Any thoughts?
First off, no need to apologize. Development can proceed at a leisurely pace, please don't feel obligated or rushed :)
I assume by MatrixStruct you mean MatrixBuilder? I am opposed to removing the hash from MatrixBuilder, it will play an increasingly important role for code generation in that class. For the time being, please make the likely_hash declaration in MatrixBuilder mutable and then you can change the hash value from the const functions. This is obviously a hack, but seeing the complete working implementation first will help me decide on the right approach.
Thanks!
Apologies I do mean MatrixBuilder not MatrixStruct. I am confused as to why the hash associated with v which is accessible by the hash() function and the likely_hash h are both necessary if they should in fact be the same.
The hash() function returns an LLVM IR Value that represents the hash of a matrix at run time. We would like for our casting code to know the hash at compile time in order to compile the appropriate cast logic. So, yes, we could implement casting using hash() instead of h, but to do so we would have to introduce run time logic to check the hash value and make the appropriate cast call.
However, one of the premises of Likely is that this information can be known at compile time, and that compile time information is provided by h. Having this knowledge at compile time is one of the fundamental important concepts that allows Likely to generate code that is potentially faster than equally generic C/C++ code: just-in-time compilation allows us to move run time logic to compile time.
The down side is that we have to ensure the compile-time hash is kept in sync with the run-time hash. I agree this is inelegant, and a better idiom is needed.
Make sense?
Perfect sense :) Thanks I will implement it with h as a mutable for the time being
Done!