search

microsoft / qsharp-language

Official repository for design of the quantum programming language Q# and its core libraries
MIT License
235 stars 56 forks source link

QIR: reconsider requiring __quantum__rt__int_power(i64, i64) method #28

Closed IrinaYatsenko closed 3 years ago

IrinaYatsenko commented 3 years ago

Instead of requiring the RT vendors to implement fast full precision integer exponents, consider adding runtime checks to generated QIR that the arguments can be losslessly converted to the types supported by one of the llvm's intrinsic powi/pow functions.

bettinaheim commented 3 years ago

@alan-geller We need to make a general call around whether we have certain cases where a 32-bit integer is required. For practical purposes, I would not require that the signature here is i64; it seems to me that realistically, there will be cases that will fail at runtime for this particular function. My inclination here would hence be to make this a (i64, i32) signature and introduce a runtime function for i64 to i32 conversion that will potentially throw at runtime. Thoughts?

IrinaYatsenko commented 3 years ago

There are intrinsics for double/float base and int power. The spec also provides for BigInt base.

alan-geller commented 3 years ago

There are definitely places already where we have value restrictions on operators; for instance, bitwise shifting is only defined for shifts of less than 64 bits. I think having a value restriction that the power that an integer may be raised to has to be 2^31-1 or less is perfectly reasonable; then we wouldn't need that runtime function at all, as @irinayat-MS's original comment points out.

Personally, I would generally prefer to keep the types in the runtime function signatures limited to the types we use for program data, and specify that those functions can fail if the value is outside a valid range, than introduce new types into the runtime signatures.

bettinaheim commented 3 years ago

@alan-geller Alright, let's see if we can get away with not introducing i32 - we can reconsider if we see that more and more cases come up where we have a i64 signature that in reality is not supported. I would want to restrict the valid values for the rhs in exponentiation to what is commonly supported, and we should document that, along with other restrictions e.g. on bitshifts. Do you mind looking into that?